#Cluster A.V - Constitutional Principles of the Kernel

Preface node heading:cluster-a-v-constitutional-principles-of-the-kernel:21458

#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

#Strict Distinction (Clarity Lattice)

Status: Stable

#Use this when

Use this pattern when one sentence, diagram, card, identifier, file, plan, or run is being read as several nearby FPF objects and the team needs to recover the exact relation position before checking the recovered claim under its exact subject predicate. A frequent case is deciding whether the live object is a Method, an episteme that qualifies as MethodDescription, a system Capability, a WorkPlan, or dated Work.

What goes wrong if missed. A label such as algorithm, SOP, recipe, or script is treated as membership evidence; a direct Method reference is forced through a document; or a description, plan, capability and occurrence inherit one another's force.

What this buys. A practitioner can identify the current object, make the smallest direct claim, and stop without manufacturing a description, execution, evidence, gate, or authority relation.

Primary working object. The exact sentence or publication position whose nearby objects have been conflated. A.7 restores the distinctions; A.3.1 is the pattern for the Method, C.2.1 is the pattern for episteme identity, A.3.2 is the pattern for same-individual U.MethodDescription membership, A.15 is the pattern for plan and Work, and naming/reference patterns contain the defining content for designation and resolution.

First useful move. Name the object the receiving use actually needs. For a suspected MethodDescription, first identify one admitted U.Episteme, then require one admitted U.Method as its exact EntityOfConcern and at least one substantive claim about that Method as a way of doing. For a direct Method use, resolve the identifier or receiving methodRef under its effective reference scheme; do not invent a MethodDescription.

Not this pattern when. If the current object and direct relation are already clear, use the applicable pattern immediately. A.7 supplies no decision about Method identity, episteme identity, MethodDescription membership, capability adequacy, work readiness, occurrence, evidence, publication, or gate passage; handle each such claim under its applicable pattern.

#Intent

Provide a single, didactically clear lattice of distinctions that keeps models free from category errors. This pattern is the guard‑rail that prevents four recurrent confusions:

1. System-role kind vs function (classification vs behaviour),
2. MethodDescription vs Method vs Capability vs Work (description vs abstract way-of-doing vs system ability/envelope vs performed occurrence),
3. Holon vs System vs Episteme (what can act and what cannot),
4. EntityOfConcern vs Description episteme, View, and Publication (the item under concern vs epistemes and publication relation positions that make it available; specification is a gated use or refinement of a Description episteme, not a third peer member of this distinction).

It harmonizes A.2 and A.2.1 for system-role kinds and system-role-assignment relations, A.3.4 for transformation, A.10 for evidence-provenance and carrier and source-currentness relations, A.14 for advanced mereology, A.15 for System-Role-Method-Work alignment, C.2.1 for episteme constitution and its separate empirical-grounding and edition relations, E.17 for publication and view discipline, and F.9, F.17, and F.18 for bridge and naming discipline.

#Problem frame

• Holons (A.1) and systems. All holons are part-whole units; a System can act because its organization satisfies A.1. Add a local system-role-kind classification or assignment only when the receiving claim uses that stronger distinction.
• Transformation (A.3.4), Work, and optional assignment. A claimed change names the affected entity and the direct transformation facts used by the claim. For a precise dated Work claim, use A.13 to identify the actual performer and A.15.1 to admit the Work independently. If the current claim must also identify the assignment under which the Work was performed, name that assignment and check the relation separately through F.6. F.6 identifies neither performer nor assignment, and a failed check leaves Work intact.
• Method and Work backbone (A.3.1, A.3.2, A.15). Keep MethodDescription, Method, Capability, WorkPlan, and Work distinct. Name only the values used by the current claim. A System acts; a local kind, assignment, Method, or episteme does not.
• Evidence (A.10). Knowledge claims cite evidence-provenance and carrier/source-currentness relations; epistemes never “act”; systems inspect, revise, publish, store, or rely on the carriers, publication forms, and project records that make an episteme available.

Practitioner check: if a sentence could be read as “the document decided” or “the process executed itself”, it violates A.7.

Boundary for use from other patterns: A.7 restores the EntityOfConcern, the admissible describing relation, and the publication boundary; then use the defining or testing rule for the remaining claim, with its PatternID kept only as a locator. Do not let A.7 turn an architecture, structure, work, method, evidence, characterization, or decision question into a general discussion of descriptions. If the EntityOfConcern is itself a Description episteme or view, keep the pattern centered on that episteme as the item under concern; description-of-description or publication-force issues open only when they are the exact claim being made.

#Problem

When documents blur the above lines, three classes of defects appear:

1. Category collapse. People write “function”, “role”, or “process” interchangeably; teams then disagree whether they are changing a MethodDescription, a Method, a Capability envelope, or reporting an actual Work occurrence.
2. Agency misplacement. Epistemes (documents, models) are treated as doers; collectives as raw sets; or a “holon” is used where only a system makes sense.
3. Audit failures. A MethodDescription is cited as if it were evidence; Work has no evidence carriers or time span; or a Description episteme, a Description episteme admitted for specification use, a View, publication face, publication unit, or carrier is treated as if it were the EntityOfConcern, decision, permission, gate, work occurrence, or assurance result.

#Forces

#Solution — The Clarity Lattice (normative distinctions & safe vocabulary)

#Terminology (normative): orthogonal characteristics

• senseFamily — the categorical characteristic, used by F.7/F.8/F.9: {Role | Status | Measurement | Type‑structure | Method | Execution}. Rows must be sense‑uniform.

• ReferencePlane — the referent mode per CHR: {world/external | conceptual | epistemic}.

• EntityOfConcern and Description-episteme boundary — the item under concern is separated from Description epistemes (E.10.D2, C.2.1). Specification use is a gated use or refinement of a Description episteme; the exact gate must name checkability, formality plus checkable constraint, harness, acceptance condition, C.16 measurement criterion, verification use, or another specification-granting neighbouring pattern. Specification is not a third member of the strict distinction.

• DesignRunTag — the design vs run DesignRunTag. It is not a temporal “plane”, generic layer, or stance.

• Publication face, form, unit, carrier, and rendering boundary — Description epistemes, including Description epistemes admitted for specification use, may be made available through publication units, publication forms, faces, renderings, and carriers. These publication values are not the EntityOfConcern value, not the Description episteme itself, not the specification-use gate or refinement, and not evidence, gate passage, work, assurance, or decision force by readable form. The ordinary didactic faces for architectural patterns in FPF are: {PlainView (explanatory prose), TechCard (typed cards and IDs), NormsCard (TechCard profile for checklists), AssuranceLane (evidence bindings)}. Publication faces and forms are orthogonal to the EntityOfConcern and Description-episteme boundary, to specification-use gates and refinements, and to DesignRunTag.

• Direct Description account and specification-use boundary — a Description episteme is independently identified under C.2.1 by its complete claim content, exact EntityOfConcern, and effective ReferenceScheme. A.7 introduces no universal EntityOfConcern-to-Description constructor or morphism. When it matters how the claims were produced, selected, carried, or revised, state the exact authoring, measurement, observation, model, source-use, representation, refinement, or other direct relation that is current. A later specification-use claim remains governed by the pattern that supplies its checkability, harness, acceptance, measurement criterion, verification use, or other specification-granting force.

• EntityOfConcern / episteme / publication boundary — EntityOfConcern names the item under concern; it does not name a document, publication face, carrier, or unspecified referent. A Description episteme makes claims about that exact item under its effective scheme. Publication faces, forms, units, renderings, and carriers may make the episteme available, but they do not become the EntityOfConcern, the episteme, a specification-use gate, evidence, gate passage, Work, assurance, or decision force. Formal or readable presentation creates none of those relations. A.7 establishes the following pairs and triplets. Use their names and scope exactly as below.

#System-role kind vs function-like wording, functional behaviour, capability, method, and work

• System-role kind. One local U.Kind with U.System candidates and an operative condition for a stable, assignable, work-facing contribution. Its member/non-member boundary and continuity rule complete the C.3 recovery. A practice or source reference locates the definition; it does not identify the kind. An obtaining assignment occurrence may relate a system to that kind only through a directly admitted U.SystemRoleAssignment species. The kind is not behaviour. Example: the kind currently named CoolingCirculatorSystemRole, whose ThermalLoop-7 provenance locates one definition.
• Function-like wording. A source phrase such as "function", "behaviour", "service", or "does X" may name a required transformation or effect (A.3.4), functional behaviour (A.6.F), a capability envelope, a method, performed work, a quality, or a structure. Recover the governed claim before choosing the FPF term.
• Under a system-role assignment. A System or acting holon that holds an assignment may have a Capability to enact a Method under conditions. A precise Work claim still uses A.13 to identify the actual performer and A.15.1 to admit the dated occurrence independently. Add F.6 only if the claim must also identify the assignment under which that Work was performed. The system-role kind, assignment, Method, Capability, transformation, and effect do not substitute for the Work or performer.

Safe rewrite for earlier "Holonic Duality (Substance vs Function)": Holonic Duality (Substance vs system-role kind). A U.System keeps its identity while its classifications and obtaining assignments change. A contribution named by a system-role kind may call for a Method, a Capability envelope to enact that Method under conditions, and possible Work occurrences; none follows from the kind alone.

Normative guard: Use system-role kind for that exact local U.Kind, an admitted direct species under U.SystemRoleAssignment for assignment occurrences, functional behaviour for a behaviour claim stated with A.6.F, Method for the abstract way-of-doing, Capability for a holder System's bounded ability or envelope for a Work family or result class under stated conditions, Work for the performed occurrence, and Transformation or effect wording for an actual change identified with A.3.4. Do not call the kind or assignment itself a function, and do not define Method as Capability or as the transformation or effect itself.

#MethodDescription vs Method vs Capability vs Work (description vs way-of-doing vs ability envelope vs occurrence)

• MethodDescription — one already identified claim-bearing U.Episteme whose exact C.2.1 EntityOfConcern is one admitted U.Method and whose claims, under its effective U.ReferenceScheme, say something substantive about that Method as a way of doing. A transformation or enactment concern, generic participant meanings, applicability, precondition, intended effect or preserved condition, bound, or internal method composition can satisfy the positive threshold. The labels algorithm, SOP, recipe, script, procedure, code, diagram, or design-time artifact are cues only. Authoring, revision, citation, publication, approval, or use time establishes neither episteme identity nor U.MethodDescription membership. Its publication cites A.10 carrier/source-currentness refs when the carrier is used as evidence or source.
• Method — the abstract order-sensitive way-of-doing composed with Γ_method (B.1.5). A Method is not an occurrence, description episteme, or system ability. Actual participants and operation values remain occurrence-side facts of separately admitted U.Work and its direct bindings.
• Capability — a named holder System's bounded ability or envelope for a Work family or result class, stated with its operating and resource conditions, measures, qualification window, and currentness condition. Name a Method or system-role assignment only when that exact condition or fit input is current. It is not the MethodDescription and not the performed Work.
• Work — the dated run-time occurrence (what actually happened), with resource spend (Γ_work) and temporal coverage (Γ_time).

Designation, reference, and description are different. A Method identifier designates one exact U.Method under the applicable designation rules of an effective U.ReferenceScheme. A receiving claim's methodRef separately resolves under its effective scheme to that same Method. Neither operation needs a MethodDescription. Cite a separate methodDescriptionRef only when that receiving claim actually depends on claims in an exact episteme edition that has already passed A.3.2 membership.

Minimally viable reference and membership case. Under MaintenanceReferenceScheme-2026, identifier PumpSealInspectionMethod designates exact admitted Method M-PSI. MaintenancePlan-47 is a separately governed U.WorkPlan; its methodRef = PumpSealInspectionMethod resolves directly to M-PSI, without a description hop. Episteme PumpSealInspectionGuide-e3 is independently identified by C.2.1 from its exact claim content, EntityOfConcern = M-PSI, and effective scheme. Its claims state the inspection precondition, ordered clean–inspect–classify way of doing, rejection bound, and stop; the same episteme therefore passes A.3.2 membership as U.MethodDescription. If MaintenancePlan-47 relies on those exact e3 claims, a separate methodDescriptionRef = PumpSealInspectionGuide-e3 may be cited. The plan, Method, MethodDescription, Capability and any later Work remain different objects.

Recognizable near misses. A catalogue row containing only PumpSealInspectionMethod designates or mentions a Method but is not a MethodDescription. A file named PumpSealInspectionSOP-v3.pdf supplies neither the C.2.1 episteme identity nor the substantive method claim by filename. methodRef = PumpSealInspectionMethod does not imply that a description exists. A newly authored, revised, cited, approved, published, or used episteme does not gain membership unless its exact Method EntityOfConcern and substantive way-of-doing claim satisfy the same test.

Normative guard: Never use MethodDescription as evidence of Work; never present Method or Capability as if it had happened; never define Method as Capability; never infer MethodDescription membership from form, label, lifecycle time, or use. Resolve direct Method designation and receiving references without mandatory description indirection.

#Holon vs System vs Episteme (who can act)

• System or acting holon. A System can act because its physical or operational organization satisfies A.1. An ordinary sentence may name the recognizable System by a contribution noun: The engineer designed the pump, The reviewer checked the manuscript, or The service accepted the request. Keep that wording when the System and contribution are recoverable and no receiving inference depends on a local system-role kind or assignment identity.
• System-role kind and assignment, when current. Add a local system-role-kind classification when the claim uses that classification. Add an obtaining assignment occurrence and its admitted species only when the claim says that the System held that assignment, attributes a particular Work occurrence to it, or relies on assignment identity, extent, or participants. The assignment and kind do not make the System able to act and do not act themselves.
• Capability, Method, and Work, when current. Name Capability only for an ability or envelope claim, Method only for the way of doing, and Work only for a performed occurrence. An ordinary actor sentence need not materialize all three.
• Episteme. An episteme cannot act. A System may author, revise, use, or publish it; state the actual operation, Work, carrier, publication, evidence, or source relation only when the receiving claim uses that distinction.
• Holon. Use the umbrella word only when systemness is not part of the claim. If action is asserted, the acting entity must satisfy A.1 as a System; an assignment is not the admission test.

Progressive example. The design team selected valve V-12 is enough for an ordinary design account when the team is a recoverable collective System and no later inference needs a precise Work or assignment identity. If an audit claims dated ValveSelectionWork-47, use A.13 to identify DesignTeamSelectionSystem as the actual performer and A.15.1 to admit the Work independently. If the audit must also identify the assignment under which that Work was performed, use F.6 to check ValveSelectionAssignment-47 and compare its holder with the already identified performer. Add the admitted assignment species, assigned local kind, extent, Method, Capability, and evidence only to the degree used by the audit.

#Episteme vs publication carrier and source-currentness record

• Episteme — the knowledge content (claim, model, requirement set).
• Publication carrier or source-currentness record — the physical or digital carrier for an episteme publication or stored representation (file, volume, dataset item), tracked through A.10 carrier/source-currentness relations when evidence, source, or reliance use is current.
• Use: Evidence, provenance, and reproducibility address carriers; arguments and validity address epistemes.

Normative guard: When you say “we updated the spec”, detail which carriers changed (A.10).

#Formal inclusion, world-side collection, and collective System

• Mathematical or representation inclusion — say that an element is in a set, a value fills a tuple place, or a value lies in a coordinate domain under the applicable mathematical statement. Use C.29, with A.19 when a characteristic scale or coordinate is current. No world-side belongs-to relation follows.

• World-side collection — identify the collection and use its subject-specific belongs-to rule. That rule says who or what may belong, when belonging begins and ends, whether it may recur, and how past belonging is stated. Belonging alone establishes neither parthood nor holonhood, but it does not prohibit a separately grounded constructive part relation.

• Collective System — treat a team or other grouping as an acting System only after the candidate passes all six A.1 matters. A list, formal set, catalogue, or belongs-to statement does not establish that result.

• Use the direct relation for every stronger claim:

  • ComponentOf — mechanical or structural part in systems.
  • ConstituentOf — logical or content part in epistemes.
  • PortionOf — quantitative portion with conserved extensives.
  • PhaseOf — temporal part of the same carrier over a proper interval.
  • System-role assignment — a System is the HolderSystemSlot value in one obtaining occurrence of a directly admitted U.SystemRoleAssignment species.

Normative guard: Formal inclusion establishes no world-side belonging. Collection belonging establishes neither constructive parthood nor holonhood and does not make either impossible. If a grouping is claimed to act, test it against all six A.1 matters. Add a local system-role kind, assignment, Method, Work, or constructive part relation only when that separate claim obtains.

#Operator alignment (required names)

• Γ_sys — composition of system properties (physical/systemic).
• Γ_method — composition of Method (order, branching).
• Γ_time — composition of Work histories and temporal parts.
• Γ_work — composition of resource spend and yields tied to Work. Do not track costs with Γ_method; costs (resources/yield) belong to Γ_work.

Normative guard: Avoid generic “process” for these operators. Reserve “process” for domain idioms; map internally to Method (design) and Work (run).

#EntityOfConcern and Description-episteme boundary vs publication face, form, unit, and carrier boundary (orthogonal, normative)

• EntityOfConcern-to-description boundary. A.7 keeps the EntityOfConcern and an episteme that describes it distinct; E.10.D2 supplies the Description and specification-use repair. What the EntityOfConcern value is and how it is described are different questions. A Description is a U.Episteme about that exact entity under its effective scheme. A named describing use may separately select one viewpoint when the selection changes what is read or checked. Specification is a checkable use or refinement of the Description episteme and requires checkable claims plus a named harness or validation relation; formality, acceptance, a C.16 measurement criterion, or verification practice may contribute to that test but does not substitute for it. EntityOfConcern, Description, selected viewpoint, and specification use remain distinct.
• Publication governs availability. Publication units, publication forms, faces, renderings, and carriers make Description epistemes available to readers or tools, including Description epistemes admitted for specification use. They do not become the EntityOfConcern value, the Description episteme, the specification-use gate/refinement, or an evidence/source carrier by the same relation; physical and digital carriers stay in A.10 carrier/source-currentness relations when evidence, source, or reliance use is current.
• Publication-face field pins. When Description epistemes or Description epistemes admitted for specification use are shown on TechCard, the minimal CHR-Pins are {UnitType, ScaleKind, ReferencePlane, EditionId}.
• Semantic and plane boundary. A context or ReferencePlane difference alone establishes no F.9 Bridge, CL, or trust penalty. When two exact F.17 local senses and the direct F.9 predicate establish a Bridge, cite that relation and a separate bounded-use claim; CL remains optional evidence shorthand. A cross-plane use cites its applicable plane relation. Apply a trust penalty only when a named current policy applies to the exact use.

#Same or near-same EntityOfConcern across descriptions and views

Different descriptions, views, viewpoints, publication units, or role-method-interest positions may concern the same EntityOfConcern, different entities of concern, or an unresolved candidate set. A.7 does not accept sameness by publication title, view label, carrier continuity, shared ordinary name, or common reader interest.

Use this split when the text needs to say whether two descriptions or views are about the same thing:

If the same or near-same relation needs mathematical or postulate-theory justification, A.7 stops at the strict-distinction boundary instead of pretending to prove it: use C.29 for the mathematical lens, E.18 and E.18.1 where transformation-flow, carry-through, and postulate-theory work supply the required justification, E.18 where a gate crossing is the live relation, or the relevant architecture pattern where the comparison is about structure, graph, flow, or architecture description.

#Compact relation-position recovery aid

When one visible source-side carrier, publication face, diagram, dashboard, card, model output, PublicationUnit, rendering, or generated artifact can be read as several FPF values at once, use A.7 only to recover the current relation position. Name the current EntityOfConcern, Description episteme, view, publication face, publication form, PublicationUnit, carrier, rendering, mathematical-lens use, evidence relation, gate decision, work occurrence, authority-reference relation, source-currentness relation, or source-use claim, then apply the subject pattern for that position.

This aid is not a reusable object, local record, table, or master checklist. If the direct governed claim is already clear, do not add an A.7 recovery note; cite the direct pattern.

#Direct Description account and specification-use boundary (normative)

A.7 uses no Describe_EoC_DescEp function. To say that one episteme describes something:

1. identify the Description episteme through its complete C.2.1 claim content, exact EntityOfConcern, and effective ReferenceScheme;
2. state the claims it makes about that EntityOfConcern in ordinary language;
3. when the receiving use asks how those claims arose or are carried, name the exact authoring, measurement, observation, model, source-use, representation, refinement, or other direct relation and its participants; and
4. keep any publication occurrence, form, face, carrier, evidence use, Work, or specification-use gate separate.

If the EntityOfConcern is itself an episteme, the new Description does not automatically copy, preserve, refine, or extend its claims. Any representation, source-use, comparison, refinement, or loss claim needs its own direct rule. If the EntityOfConcern is a system, structure, Method, Work occurrence, physical object, characteristic, relation, or other non-episteme, claims are likewise not “inside” it waiting to be copied; the actual measurement, observation, model, postulate, authoring, or other relation explains the claim when that explanation is current.

Example. PumpPerformanceDescription-e4 is a C.2.1 episteme whose EntityOfConcern is pump P-12 and whose claims state the measured flow and pressure under the named scheme. MeasurementRun-88 produced ObservationEpisteme-88, and that observation supports the stated measurement claim through its direct evidence-use relation. The Description, pump, measurement Work, observation episteme, evidence use, and publication carrier remain different objects. No universal constructor is needed.

A Description episteme becomes usable as a specification only through the neighboring pattern that supplies the required checkable constraints and named harness, validation, acceptance, measurement criterion, verification use, or other specification-granting force. Formal notation alone is insufficient. Specification use remains separate from the EntityOfConcern, Description identity, publication expression, and Work.

Describing, formalizing, and specifying are not execution. They carry no Gamma_method, Gamma_time, or Gamma_work actuals. Authoring or publishing them may involve separate Work with its own time and resource relations.

#Outcome specification strict distinction

A.7 supplies only the distinction. The authoritative promise-facing OutcomeSpec shape is in A.2.3:4.1.1, and the authoritative unit-of-delivery counting rule is in A.2.3:4.1.2.

An OutcomeSpec is a specification-use episteme form, not a new U-kind, a Work occurrence, an affected entity, a post-work state, an operation-result binding, or a verdict episteme. Its mode says which facts the promise constrains:

• WorkOnly constrains selected facts about one or more delivery Work occurrences;
• ResultOnly constrains the exact affected referent and required post-work state, regardless of method; and
• Composite constrains both.

Readable example. The provider cuts and styles the client's hair within 20 minutes, and the resulting hairstyle meets the stated evening-style condition. The first clause constrains delivery Work and may name the exact Method. The second constrains the client's post-work hairstyle state. Exact affected-referent, actual-change, production, delivery, acceptance, and evidence-use relations are stated only when the receiving claim needs them. No U.Work.Delta field or universal delta record is required; an optional mathematical change expression remains a separate lens when a named comparison uses it.

Evidence supports assertions about the selected Work facts, affected referent, post-work state, and direct relations. Evidence and its carrier do not become any of those facts. Counting is also separate: A.2.3's unitOfDelivery says how accepted delivery is counted and how double counting is prevented; it is not part of OutcomeSpec.

#Worked cases

#System and episteme

Digital twin and asset. Maintenance system M updated the asset configuration using Twin-e4. This ordinary sentence keeps the acting System, asset, and episteme visible. If the receiving claim concerns exact Work, carrier change, evidence, source currentness, or an assignment, add those objects and direct relations separately. The twin neither acts nor becomes the asset; a cross-plane use cites only its applicable plane relation and policy.

Review and manuscript. Reviewer Dana reviewed Manuscript-e7 and wrote Review-e2. This is valid ordinary actor wording when Dana is a recoverable System and no inference uses assignment identity. PeerReviewGuide-e2 is a MethodDescription only if its exact EntityOfConcern is the PeerReview Method and its claims say substantively how that Method is performed. For a precise audit, use A.13 to identify the review performer and A.15.1 to admit the review Work independently. Add F.6 only if the audit must also identify the assignment under which that Work was performed. Keep the resulting review episteme, manuscript and review carriers, and evidence or source relations separate.

#Progressive technical examples

Pump in a cooling loop. Pump P-12 circulated coolant during the 10:00-10:45 run. If that sentence remains ordinary actor wording, no full performance record is required. For a precise Work claim, use A.13 to identify the actual performer and A.15.1 to admit the dated run independently. Add CoolingLoopCirculationAssignment-17, its admitted species, holder and assigned-kind participants, and F.6 only if the claim must also identify the assignment under which the run was performed. Add Capability and Method only for their own claims; none follows merely from the noun pump.

Standard used in a design. The design team used Safety Standard S-174 when selecting valve V-12. The standard is an episteme and does not act. Its PDF and printed volume are carriers only when the receiving source or evidence claim uses them. Valve Selection SOP v5 is a MethodDescription only after the A.3.2 membership test; the ordinary sentence does not require an assignment. A reliance-bearing Work account uses A.13 to identify the actual performer and A.15.1 to admit ValveSelectionWork-47 independently. Add F.6 and the exact assignment only if the account must also say under which assignment the Work was performed. Evidence use and current source edition remain separate.

Set and team. {Alice, Bob, 3.14} is a set and cannot act. Cooling maintenance team T repaired pump P-12 is ordinary actor wording when T is already recoverable as a collective System. Add its coordination Method, Work occurrence, local system-role kind, or assignment only when the corresponding stronger claim is current.

#Conformance Checklist (normative)

#Canonical rewrites (didactic library)

#Anti‑patterns (with fixes)

1. System-role-kind-as-behaviour — calling the system-role kind a function or saying it acts. Fix: Name the acting System and direct behaviour or Work first. Add the local kind, assignment, Method, or Capability only when that stronger claim is current; none of them acts.

2. Episteme‑as‑system — “the model routed traffic”. Fix: Name the System that used the model. Add Work, carrier, assignment, evidence, or source details only when the receiving claim uses them.

3. Triad everywhere — omitting Work entirely. Fix: Add a Work occurrence only when performed action is claimed; a design-time distinction diagram need not pretend that Work occurred.

4. Operator blur — using one “process operator” for everything. Fix: Choose among Γ_method, Γ_time, Γ_work, Γ_sys.

5. Formal set, world-side collection, and collective collapse — mathematical inclusion or collection belonging is used to make a grouping act or to infer constructive parthood. Fix: Keep formal inclusion with its mathematical or representation rule; state world-side belonging under the collection's own rule; require all six A.1 matters for a collective System; state any constructive part relation separately.

6. Evidence without carrier references — citing ideas without carriers. Fix: Add A.10 carrier/source-currentness refs and tie claims to evidence or source relations.

7. Holon/system drift — “holon maintains temperature”. Fix: Say system; reserve “holon” for neutral mereology.

8. Function and system-role-kind swap in tables — columns labelled “Function” whose entries are local system-role kinds. Fix: Rename the column to System-role kind; add a separate Behaviour (Method and Work) column.

9. Process‑word leakage — domain “process” used as FPF operator. Fix: Add parenthetical mapping at first use (Method and Work).

10. Carrier and episteme swap — “we versioned the model” meaning a file was renamed. Fix: State whether the episteme content changed; if only a carrier was renamed, say so.

11. Publication-as-mechanism — modelling “publication” as if it were a Method or Mechanism. Fix: Identify the Description episteme directly through C.2.1 and keep specification use and publication separate. Name an actual authoring, measurement, observation, model, source-use, representation, or refinement relation only when current; operational build, render, or upload activity is separate Work by a System on carriers.

12. Form-first MethodDescription — “this is an SOP/algorithm/script, therefore it is a MethodDescription.” Fix: Identify the C.2.1 episteme, resolve one admitted Method as its exact EntityOfConcern, and find at least one substantive way-of-doing claim; otherwise retain only the source cue.

13. Mandatory description hop — a Method identifier or receiving methodRef is forced through a document or description edition. Fix: Resolve designation and the receiving reference directly to the exact Method under their effective ReferenceScheme discipline; cite methodDescriptionRef separately only when its claims are actually used.

14. Lifecycle time as membership — authoring, revision, citation, approval, publication, or use is treated as creating MethodDescription membership. Fix: Keep those Work and neighboring relations under their subject patterns; reapply the same A.3.2 membership test to the independently identified episteme.

#Consequences

#EntityOfConcern and publication-boundary consequences

#SoTA‑Echoing (post‑2015 practice alignment)

• Digital Twins (ISO 23247, 2021→): separates the asset (system) from its digital representation (episteme) and prescribes governance of twins without attributing agency to the twin itself — matching A.7’s “episteme ≠ actor” and carrier discipline. Adopt.
• Observability (OpenTelemetry, 2019-2025): codifies semantic conventions as publication-form discipline over traces, metrics, and logs; semantics are governed by descriptions, not exporters, echoing A.7 publication-face and publication-form orthogonality. Adapt (terminology).
• Active Inference (2017→2024): separates a generative model (episteme) from actions by the agent (system), with explicit perception–action cycles — mirroring A.7’s “who can act” and stance separation. Adopt
• Constructor Theory (2016→): frames knowledge and work as possible transformations enacted by constructors (systems), not by informational states — reinforcing “episteme ≠ actor”. Adopt
• Quality‑Diversity (MAP‑Elites family, 2015-2024): archives are sets on typed spaces (descriptions) whose occurrences are runs; selection returns sets under admissible orders, consonant with A.7 and A.15’s set-returning discipline. Adopt and adapt.
• Refinement-typed specs (2016->): modern refinement-typed specification toolchains (e.g., Liquid Haskell, Dafny's post-2017 refinements, Rust's uom type-level units) treat formalization as monotonic refinement with pinned units and scales. A.7 uses them only to motivate the specification-use boundary; the refinement laws belong to the neighboring pattern governing the claiming specification, formality, measurement-criterion, and publication patterns. Adapt (terminology; pinning discipline).

#Rationale (informal)

• Engineering cognition: Large programmes fail less from equations than from category slips (“process vs procedure vs execution”). A.7 eliminates these slips by a small, repeatable grammar.
• Compatible with ISO/BORO practice: Distinguishing reusable ways of doing, claim-bearing description epistemes, system capabilities, and dated operations mirrors established systems-engineering discipline while keeping FPF’s holonic rigor; procedure-like labels remain cues rather than kind evidence.
• Didactic primacy: Practitioners start with a readable sentence naming the System, action, subject, or Description. They add assignment, local system-role kind, Method, Capability, WorkPlan, Work, MethodDescription, carrier, source, or evidence relations only when the current claim uses those distinctions.
• Why name publication faces and forms in A.7? Strict Distinction already guards the EntityOfConcern value from the Description episteme that makes claims about it. In practice, misreadings happen at the publication face: cards and tables are mistaken for EntityOfConcern values; governance words leak where physics or logic should stand. Naming publication face, form, unit, carrier, and rendering uses as orthogonal closes that gap without entangling semantics with any tool or notation. Specification use or refinement is also named only to keep it orthogonal to EntityOfConcern, Description, and publication expression. This preserves C-1 universality and P-1 Cognitive Elegance, while giving E.8 a crisp governing source for multi-face presentation rules.

#Relations

Builds on: A.1 (Holon), A.2 and A.2.1 (system-role kinds and system-role-assignment relations), A.3.1/A.3.2/A.3.4 (Method, MethodDescription, Transformation), A.10 (evidence-provenance, carrier, and source-currentness relations), A.14 (Advanced Mereology), A.15/A.15.1/A.15.2 (System-Role–Method–Work, Work, and WorkPlan Alignment).

• Constrains: A.13 (Agency sits on systems only; epistemes non‑behavioural), Part B operators (Γ_method/Γ_time/Γ_work/Γ_sys) and their choice points; publication is not a Γ‑operator.
• Extends: E.8, E.10, Part F and Part G, B.3, and the C-cluster by enforcing the EntityOfConcern/Description boundary, specification-use and publication orthogonality, System/Episteme separation, same or near-same EntityOfConcern discipline across views, and progressive actor wording. Publication remains the separately governed availability of an exact episteme through a form and carrier.
• Coordinates with: E.18 for crossing visibility, A.21 for gate checks, E.17 for publication, and E.10 for lexical checks. F.17 identifies exact local senses and F.9 governs an obtaining Bridge between two such senses; a ReferencePlane crossing follows its applicable plane relation. The bounded-use claim, reliance, optional CL, and any named policy penalty remain separate.

#Practitioner one-page review (copy-paste)

Ordinary approval sentence

Engineer Dana repaired pump P-12. MaintenanceNote-e4 describes the repair. Carrier C bears publication form F.

Keep the sentence this short when the receiving use needs no stronger distinction. Contribution nouns such as engineer, reviewer, pump, team, or service are acceptable when the underlying System and contribution are recoverable and no decision, attribution, admission, or reliance depends on a hidden kind or assignment identity.

Reliance-bearing expansion, when needed

A.13 identified System S as the actual performer, and A.15.1 independently admitted Work W. If the receiving account must also say under which assignment W was performed, F.6 checks that relation against assignment A and compares S with A's holder; W enacted Method M. Capability C, local system-role kind K, method-description episteme D, carrier P, evidence-use relation R, time, and resources are named only where the receiving claim relies on them.

Six checks

1. Acting subject: Is the acting System recoverable? If assignment identity is not used, do not invent it.
2. Current distinctions: Are Method, Capability, Work, assignment, local kind, and MethodDescription named only for claims that actually use them?
3. Description boundary: Is each Description episteme independently identified by claim content, EntityOfConcern, and effective scheme, with any authoring, measurement, source-use, representation, or refinement relation stated separately?
4. Right operator: Gamma_method composes Method; time and resource actuals belong to Work or their direct relations.
5. Episteme and carrier: Does the episteme remain non-acting and distinct from its publication form and carrier?
6. Grouping: If a group acts, is it recoverable as a collective System rather than merely a set?

Diagram legend stub

• process in source language may mean Method, Work, transformation, mechanism, or another direct object; recover the live claim.
• A system-role-kind column lists local classifications, not behaviour.
• A behaviour column shows the Method or Work actually current; it need not display a full assignment chain.

#A.7:End

#Consequence-Guided Ontological Problem Solving

Type: Architectural (A) Status: Stable Normativity: Normative

#Use this when

Use this pattern when a clear or apparently clear engineering claim produces the wrong action, identity, dependence, obtaining, responsibility, or projection consequence, and a typed or constructive distinction may repair it. One grounded counterexample or one subject-pattern invariant can trigger the work; you do not need two polished alternative ontologies before starting.

The first useful move is to state the affected engineering result and the smallest defeated or disputed claim, then enter the first diagnostic locus that can change that result. Stop as soon as an admitted working account determines the next move truthfully.

Not this pattern when. If the blocker is missing observation or evidence, reopen the exact domain or evidence question and its predicate. If wording alone hides the distinction, use C.2.P or E.10. If the problem is a material premise conflict between FPF methods, use A.7.2. If a missing distinction must become durable FPF ontology, require E.24/E.24.UK, A.8, and A.11 rather than admitting it here.

The primary reader is a domain engineer or ontology analyst responsible for the affected use. This pattern is a U.MethodDescription; it does not act. When actual ontology-analysis Work is claimed, recover the exact performing U.System through A.13 and let A.15.1 independently admit the dated U.Work and enacted Method. Add F.6 only when the analysis result also consumes precise assignment-bound attribution through the same obtaining A.13 assignment; missing or failed F.6 leaves the Work intact. The reader, performer System, MethodDescription episteme, Method, any assignment and attribution, Work, and returned engineering result remain separate.

#Problem frame

A maintenance sentence can be lexically clear and still merge two relation occurrences across removal and reinstallation. A responsibility claim can use a plausible system-role word or assignment while omitting the direct responsibility predicate and its participants. A graph or logical type can look exact while omitting the construction that changes the action. In these situations, a glossary is too little and an exhaustive ontology exercise is too much.

The governed concern is the smallest ontology-analysis application that changes one declared engineering use, result, or guarantee. The ordinary product is a repaired statement, Method choice, action, subject-qualified result, or explicit blocker—not an ontology artifact by default.

#Problem

Ontology work often starts from available vocabulary rather than a failed consequence. That encourages blanket constructive replay, premature kind admission, and durable records even when direct kinds and relations already decide the next action. The opposite failure treats clear words as sufficient and leaves a category error inside Work, evidence, system-role-kind, assignment, state, capability, relation, responsibility, or representation claims.

The practical question is not “How much ontology can we recover?” It is “Which distinction changes the engineering move at the required guarantee, and what is the cheapest truthful return?”

#Forces

#Solution

#Retain the complete application boundary

This A.7.1 U.MethodDescription episteme narrows the method claims stated by C.19.2 for consequence-guided ontology analysis. When applying A.7.1, retain the declared use, problem-facing result, claimed guarantee, horizon, useful threshold, and separation among the MethodDescription episteme, described Method, reader, A.13-qualified performing System, independently admitted dated Work, and result. Add a separately declared assignment species, obtaining occurrence, and F.6 attribution only when the receiving analysis use expressly consumes that precise assignment-bound attribution. A missing or failed F.6 relation leaves the Work intact. This wording adds no relation occurrence between the described Methods.

The normal short path uses the already selected A.7.1 analysis method as its one current apparatus. It begins from one exact engineering subject, exact subject predicate, and the pattern description locating that predicate; subject and predicate are inputs and constraints, not apparatus candidates. Use C.18 only when the team must generate or reframe alternative analysis methods, models, formalisms, or other direct-kind apparatuses for the same declared use. Use C.11 only when two or more already-available apparatuses are eligible for that same use and guarantee, making a real local-choice question current. After selection, use the planning Method described in A.15.2 and identify dated Work under the predicate defined in A.15.1; C.24 enters only for tool-call enactment planning.

#Start from the defeated consequence

Name five things in ordinary domain language:

1. the affected engineering result and its required guarantee;
2. the smallest claim whose current reading fails or is disputed;
3. the observed consequence failure, subject-pattern invariant, or grounded counterexample;
4. at least one candidate correction or a request to recover one; and
5. the action that must remain blocked until the distinction is settled.

One defeated reading is enough. Recovering or constructing an alternative can be part of the work.

#Enter one of four diagnostic loci

The four loci are a named diagnostic set; they are not a mandatory sequence.

1. Domain inquiry. Ask whether the relevant behaviors, interventions, evidence, and consequences are known. If not, return domain, measurement, or evidence work without ontology invention.
2. Wording use. Ask whether one term or sentence obscures distinct claims. Use C.2.P or E.10 only when wording precision is the live blocker.
3. Working typed account. Test whether direct kinds, participant positions, relation direction, temporal qualification, evidence relation, and occurrence identity suffice for the use. Reuse the direct relation, local system-role-kind, system-role-assignment, state, capability, Method, Work, responsibility, and evidence patterns already in FPF.
4. Subject-specific constructive ground. Return to the exact subject construction only when action, identity, dependence, obtaining, constitution, or decision-changing CT2R loss differs across constructions. Use the direct relation-occurrence, local system-role-kind, direct U.SystemRoleAssignment species, system-recognition, Work-occurrence, state or capability, responsibility, or structural-construction pattern. Do not default to C.13 or a generic constructive calculus.

#Perform only consequence-changing ontology work

1. Select the first locus capable of resolving the delta.
2. Have the admitted system perform the required domain, wording, typing, evidence, or construction work.
3. Use exact A.7.CP claim IDs through ClaimUsedAsReasoningBasisRelation@Context only when those claims are load-bearing in the work. Do not traverse the compact by default.
4. Preserve direct evidence, currentness, source-use, kind-admission, and subject-construction patterns.
5. Return the repaired result immediately when the next action is truthful at the declared guarantee.

The method result uses one of these closed local dispositions in its result episteme: repairedEngineeringStatement, methodChoice, actionSelected, noOntologyIntervention, returnToDirectOwner, or unresolvedWithBlocker. These are method-result dispositions, not new U-kinds. Each names the affected use, practical result or blocked claim, and stop/reopen condition.

#Decide whether the working account is enough

A working account is sufficient when admitted direct kinds and relations determine the next move and plausible constructional alternatives do not change the result or guarantee. Stop without declaring the alternatives false. Do not create an occurrence ledger, evidence apparatus, publication package, or ontology record whose distinctions cannot change the use.

Create a durable ontology result only when reuse, dispute, high consequence, automation, or cross-pattern change makes persistence valuable. If the work exposes a missing distinction that must persist, submit the candidate for E.24 admission and return only after a positive admission result.

#Reopen and teach without premature structure admission

Reopen on a consequential counterexample, changed guarantee, failed use, projection loss, changed occurrence identity, or a newly admitted subject-pattern distinction. Reopen only the affected engineering and ontology decisions.

A short domain, wording, typed-account, or constructive-ground presentation may remain an ordinary explanation or, when persistence matters, a C.2.1 episteme about the question and proposed alternatives. It is not a CGUS, method, plan, Work occurrence, or result. A reusable CGUS requires one identified A.22 structure, local locus bindings, selected relations and applied constraints, and at least two potential continuations; its present-case continuation results remain separate.

#Archetypal Grounding

Support occurrence repair. A maintenance claim says bearing B1 continued supporting shaft S1 after removal and reinstallation. The direct relation identity rule defeats that reading before a second ontology is written. The A.7.1 analysis method is already selected, while the current support-relation pattern constrains the disputed claim; neither the bearing/shaft subject nor that subject pattern is an apparatus candidate, so the work creates no option set. Ontology-analysis work uses A7CP-01 and A7CP-10, recovers two support occurrences, repairs the warranty and incident-attribution claim, and returns it to maintenance. No new relation kind or U-kind is created.

Missing telemetry non-use. A team cannot determine pump state because telemetry was never collected. State kinds, evidence relations, and candidate actions are already clear. The result is returnToDirectOwner for measurement and evidence work with the blocked state claim; no premise-use occurrence or ontology artifact is minted.

Construction-changing case. A maintenance set uses “part” both for an item that belongs under the set's own rule and for ComponentOf. Removing the item changes the construction only in the ComponentOf case. Apply C.13 to the disputed item's construction, repair the maintenance claim, and leave unrelated belongs-to claims unchanged.

#Bias-Annotation

Lenses tested: Gov, Arch, Onto/Epist, Prag, Did. Scope: engineering uses in which ontology may change a practical result.

Ontology-display bias favors elaborate category systems even when existing predicates and current facts already decide the case. Lexical bias treats clear wording as proof of sound ontology. Evidence bias converts unresolved reliance into a third world state. The mitigation is a defeated consequence, first-capable locus, subject-qualified result or blocker, and positive stop.

#Conformance Checklist

#Common Anti-Patterns and How to Avoid Them

#Consequences

The pattern gives ontology work a practical exit. It can repair a consequence-changing conflation, return to the real blocker, or stop at an adequate working account without pretending the rest of ontology is false. The cost is naming the defeated claim and the work/result boundary. The benefit is less speculative ontology and more reliable engineering action.

#Rationale

Ontology effort should scale with changed consequence, not with available vocabulary. A subject-pattern invariant or grounded counterexample provides a better start than a universal checklist because it exposes why the current account fails. Four loci preserve the common places where repair occurs without forcing an order. The description-level narrowing of C.19.2 carries the economics, work separation, and truthful one-apparatus path instead of duplicating them loosely.

Repair only the ontology that changes the engineering move.

#SoTA-Echoing

These sources change the working method and its cases. They do not license a fixed explication ladder, exhaustive ontology traversal, or replacement of domain evidence by conceptual work.

#Relations

• Description-level specialization: A.7.1 narrows the method claims stated by C.19.2. On the ordinary one-apparatus path, the already selected A.7.1 analysis Method is the direct-kind apparatus; the engineering subject and its subject pattern remain inputs and constraints. A.7.1 retains the declared use, problem-facing result, claimed guarantee, horizon, useful threshold, the distinct MethodDescription episteme and described Method, reader, A.13-qualified performing System, independently admitted dated Work and result, and the stop and reopen conditions. A separately declared assignment species, obtaining occurrence, and F.6 attribution enter only when the receiving use expressly consumes exact assignment-bound attribution. It retains C.18 and C.11 candidate and choice behavior only for alternative analysis Methods, models, formalisms, or other applicable apparatuses eligible for the same use and guarantee. This wording adds no relation occurrence between the described Methods and asserts neither U.SubkindOf nor a world relation.
• Consumes: exact A.7.CP claim epistemes through ClaimUsedAsReasoningBasisRelation@Context only when the ontology-analysis work relies on them.
• Coordinates with: A.7.2 when a material cross-pattern premise conflict is current; neither method is the other's parent or source of premise truth.
• Returns to: direct relation, local system-role-kind, assignment, System, state, capability, Method, Work, responsibility, evidence, temporal, structural, and domain patterns for the claim being repaired.
• Escalates durable ontology to: E.24/E.24.UK, A.8, and A.11; it does not admit U-kinds or relations itself.
• Preserves: current A.7 Strict Distinction and A.22.CGUS admission law.

#A.7.1:End

#FPF Ontology-Premise Reconciliation

Type: Architectural (A) Status: Stable Normativity: Normative

#Use this when

Use this pattern when two or more dated applications of current FPF methods or patterns yield ontology-claim or decision epistemes whose claims or practical consequences cannot jointly support the same receiving claim or consequence in the same scope. Trace each result to the exact pattern or method clauses, premises, and accepted source-use occurrences that the application actually used; a difference between texts alone is not a conflict. One material contradiction is enough; recurrent conflict is not required.

The first useful move is to name the smallest receiving ontology claim and, for each dated application, the result claim or decision, the practical consequence it would support, and the exact clause, premise, or source use on which it relied. If the result claims or consequences differ by scope, stop with a context split instead of forcing agreement.

Not this pattern when. A vocabulary difference, unlike source function, or different subject with no shared practical consequence is not a premise conflict. Use A.7.1 for one engineering ontology defect, C.2.P/E.10 for wording use, direct evidence-use or formal patterns for missing warrant, and source-currentness patterns for stale editions.

The primary reader is an FPF maintainer, architecture steward, or pattern author responsible for a material cross-pattern contradiction. This pattern is a U.MethodDescription episteme that describes a U.Method. For any precise dated reconciliation U.Work, use A.13 to identify the actual performer System and let A.15.1 independently admit the occurrence. If the case or receiving result must also identify the assignment under which the reconciliation Work was performed, check that relation separately through F.6 against the assignment used by A.13. A short result may omit an assignment identifier it does not use; no unused assignment or attribution is presumed. The pattern episteme, described Method, reader, performing System, any separately established assignment species and occurrence, optional assignment check, Work, source uses, and returned FPF decision remain distinct.

#Problem frame

Neighboring FPF pattern epistemes and U.MethodDescription epistemes can state different premises about existence, constitution, identity, dependence, obtaining, representation, agency, or formal projection. A dated application of a system-role-assignment method clause may yield a decision claim that assignment Work or a policy-valid instituting act must occur before an individual commitment obtains, while an application of a relation-method clause may yield a claim that a signed chart constitutes that same assignment. Both texts may be internally clear, yet the application results can conflict about assignment constitution, duty, or responsibility for one maintenance action.

The governed concern is one bounded reconciliation of exact FPF receiving claims and their practical consequences. The ordinary result can be compatibility, separation, non-composition, no-conflict stop, or unresolved escalation. Convergence is not mandatory.

#Problem

A premise catalogue does not repair dated applications whose result claims conflict. Prestige ranking of sources can hide the receiving claim, while broad foundation rewriting can damage unrelated pattern decisions. Conversely, treating different source functions as automatically incomparable can leave a real same-claim contradiction unresolved.

Reconciliation must recover what each Work occurrence actually used, what source content bore on the named claim, the exact evidence and currentness predicates and assertions, and which smallest FPF decision must reopen.

#Forces

#Solution

#Recover the exact conflict

1. Name the smallest disputed receiving ontology claim and its current edition.
2. For each dated application, name its resulting ontology-claim or decision episteme, the practical consequence the receiving use would take from it, and the exact method clause, premise, or source-use occurrence on which the work relied.
3. Recover the exact FPF claim epistemes, dated application-work occurrences, direct kinds and relations, A.7.CP reasoning-basis occurrences, source-use occurrences, scope, and currentness.
4. Test whether the result claims support incompatible answers to the same receiving claim or practical consequence in the same scope. If not, return noConflictStop or contextSplit.
5. Compare exact source content through direct evidence, formal-semantics, domain, scope, and currentness patterns. Do not rank source labels.
6. Translate candidate distinctions into FPF objects and constructive consequences. Test them against subject evidence and only the A7CP-* claims used by the reconciliation work.
7. Reopen the smallest FPF decision set, preserve unaffected subject-pattern decisions, and repair the method clause or subject-pattern decision that caused the dated applications to yield incompatible results. Run enough of the affected application again to obtain a checked result; do not stop at rewriting a premise list.
8. Return one declared result with affected use, stop, and reopen condition.

#Use one closed reconciliation result set

The result episteme uses exactly one local disposition:

• reconciledCompatibility — repaired clauses and checked application results now support compatible use for the named claim and scope;
• contextSplit — the claims or constructions are valid only in different named contexts or scopes;
• doNotCompose — both may remain current, but their outputs must not be combined for the named use;
• unresolvedEscalation — evidence or decision authority is insufficient, with the exact blocked use and receiving subject pattern named;
• noConflictStop — the apparent conflict disappears after claim, consequence, or scope recovery.

These are reconciliation-result dispositions, not new U-kinds. Compatible co-use is demonstrated only when warranted. A current conflict does not have to end in one winner.

#Record claim-relative source use

OntologyClaimSourceUseRelation@Context records how one dated ontology-decision or reconciliation work occurrence actually consumes one source episteme for one receiving ontology claim. It is local to this use and does not create a universal source-authority relation.

OntologySourceUseFunctionValue ::=
  formulateReceivingClaim
  | constrainReceivingClaim
  | testOrStressReceivingClaim
  | interpretFormalOrImplementationSemantics
  | compareReceivingAlternatives
  | traceLineage

OntologySourceUseDispositionValue ::=
  adopt | adapt | reject | comparatorOnly | lineageOnly | unresolved

ReceivingClaimChangeDispositionValue ::=
  changed | unchanged | undeterminedPendingResolution

OntologyClaimSourceUseRelation@Context <: U.Relation

RelationSignature:
  SourceEpistemeSlot:
    SlotKind: SourceEpistemeSlot
    ValueKind: U.Episteme
    refMode: U.EpistemeRef
  ReceivingOntologyClaimSlot:
    SlotKind: ReceivingOntologyClaimSlot
    ValueKind: U.Episteme
    refMode: U.EpistemeRef
  OntologyDecisionWorkSlot:
    SlotKind: OntologyDecisionWorkSlot
    ValueKind: U.Work
    refMode: WorkRef

semanticDirection: SourceEpistemeSlot -> ReceivingOntologyClaimSlot
  through the named OntologyDecisionWorkSlot

RelationOccurrenceQualifiers:
  sourceUseScope: U.ClaimScope
  useFunction: OntologySourceUseFunctionValue
  sourceContentSliceRef?: U.EpistemeRef
  sourceContentKindRef?: U.KindRef
  modelUseStructureRef?: U.StructureRef
  sourceCurrentnessResultRef?: U.EpistemeRef
  receivingClaimCurrentnessResultRef?: U.EpistemeRef
  landedFPFDecisionRef?: U.EpistemeRef
  evidenceUseRelationRefs[]?: U.EntityRef
  disposition?: OntologySourceUseDispositionValue
  blockedOverreadRef?: U.EpistemeRef
  receivingClaimChangeDisposition?: ReceivingClaimChangeDispositionValue

OccurrenceIdentity:
  <exact source-episteme edition,
   exact receiving-claim edition,
   exact ontology-decision work occurrence,
   useFunction,
   sourceUseScope,
   maximalContinuousUseInterval>

The source participant is the source episteme and edition consumed. The receiving participant is the ontology-claim episteme and edition being formulated, constrained, tested, interpreted, compared, or traced. For the Work participant, use A.13 to identify the actual performer and A.15.1 to admit the dated ontology-decision U.Work independently. If the case must also identify the assignment under which that Work was performed, F.6 checks the assignment used by A.13 and compares its holder with the already identified performer. The assignment neither supplies the System nor performs the Work, and an unused assignment check need not obtain.

The minimal occurrence needs only those three exact participants, useFunction, sourceUseScope, and the derived maximal continuous interval during which the named work actually consumes content from that source episteme for that receiving claim. Citation, access, bibliography membership, prestige, publication status, or co-location alone is insufficient. If the work consumes only a separately identified claim or content episteme inside the source, sourceContentSliceRef names that slice; it does not duplicate the source participant under a bundle alias. Changing a source or receiving-claim edition, work occurrence, function, scope, or demonstrated actual-use interval identifies another occurrence. A changed optional qualifier identifies another occurrence only when it changes the content or direct use predicate; a later review record alone does not.

Add modelUseStructureRef only when one independently selected BoundedModelUseStructure changes interpretation of this use. Add source-content kind, currentness-result, landed-decision, evidence-use, disposition, blocked-overread, or receiving-claim-change references only when the reconciliation work actually asserts or consumes that item under its subject pattern. A recorded unresolved disposition needs no fabricated blocked-overread episteme; unchanged is recorded only when the work actually reaches that result, while absence of a change disposition remains no claim.

#Identify source-use conflict without ranking traditions

OntologySourceUseConflictFinding@Context <: U.Episteme cites two or more exact source-use occurrences and states a conflict only when their content bears on the same receiving claim or same practical consequence in the same scope and their conclusions cannot jointly hold.

Different use functions are neither automatically comparable nor automatically insulated. Compare their exact content through direct evidence, formal-semantics, domain, scope, and currentness patterns. A finding can support adoption, adaptation, rejection, context split, non-composition, or unresolved return only with the exact counterexample, contradiction, proof consequence, or evidence relation that warrants it. “Stronger source” without claim-specific grounds is not a resolution.

#Stop and reopen

Stop with noConflictStop when the shared claim or consequence disappears after recovery. Stop with contextSplit or doNotCompose when that boundary truthfully protects the use. Stop unresolved only with the exact missing evidence basis or decision predicate and source and blocked use.

Reopen when a source or receiving-claim edition changes, currentness changes, new domain or formal evidence bears on the same claim, a blocked overread becomes relevant, a landed decision changes, or later dated applications of repaired clauses yield incompatible same-scope consequences. Reopen only affected source-use, application-result, and receiving decisions.

#Archetypal Grounding

Compatible repair. One dated method application yields a claim that a policy-valid instituting act creates MaintenanceCommitment-17, an exact U.Commitment whose actual bearer is MaintenanceSystem-4; it does not thereby establish responsibility. Another application yields a claim that a signed organization chart is sufficient to make MaintenanceAssignment-17 : MaintenanceCoordinatorAssignment obtain. Reconciliation Work recovers both result claims, their method clauses, source uses, and reasoning-basis uses of A7CP-01, A7CP-03, A7CP-05, and A7CP-06. It repairs the assignment clause so the chart is evidence for an assignment assertion rather than constitution of the assignment. If responsibility is also claimed, it is tested independently under an admitted maintenance-responsibility predicate with actual participants, applicability, and identity; otherwise the exact missing governor is returned. The result is reconciledCompatibility: commitment, assignment, responsibility, performing system, and Work no longer substitute for one another, while unrelated evidence and publication law stays unchanged.

Context split. One dated application uses a pattern's ComponentOf clause for a pump assembly; another applies a maintenance-set pattern's belongs-to rule to a candidate item. Both result claims say “part”, but their subjects, receiving claims, constructions, and consequences differ. The result is contextSplit; neither source clause nor application result defeats the other.

Non-convergence. Two dated method applications yield incompatible same-scope dependence claims, but available evidence and formal consequences warrant neither correction. The result is doNotCompose for the affected assurance use or unresolvedEscalation with exact result claims, missing evidence basis or decision predicate and source, and reopen condition. Familiarity or institutional status cannot manufacture convergence.

#Bias-Annotation

Lenses tested: Gov, Arch, Onto/Epist, Prag, Did. Scope: material cross-pattern ontology-premise conflicts in FPF.

The dominant biases are prestige hierarchy, forced convergence, and formal-shape authority. The mitigations are claim-relative source-use occurrences, same-claim/same-consequence tests, direct evidence/currentness patterns, a smallest-decision repair, and truthful context-split/non-composition outcomes.

#Conformance Checklist

#Common Anti-Patterns and How to Avoid Them

#Consequences

FPF gains a way to repair foundation conflicts without a total source hierarchy or an omnibus ontology pattern. The method can prove compatible co-use, preserve scoped pluralism, block composition, or return unresolved with an accountable reopen. The cost is exact source/receiving/work and currentness recovery; that cost is paid only for material conflicts.

#Rationale

The receiving claim supplies the adjudication question. This keeps source kind, currentness, evidence use, local use function, disposition, and claim change orthogonal. Repairing the smallest method decision preserves corpus stability, while non-convergence outcomes prevent a neat vocabulary from overruling absent evidence.

Repair the smallest foundation conflict; do not manufacture one foundation.

#SoTA-Echoing

Each row changes a source-use or comparison boundary in the Solution and cases. No row grants total authority to a source family, and a newer publication alone does not reopen unrelated FPF decisions.

#Relations

• Coordinates with: A.7.1. A.7.2 is neither its parent nor child; it handles material cross-pattern premise conflict and can return repaired subject-pattern decisions to it.
• Consumes: exact claim contents from A.7.CP through actual ClaimUsedAsReasoningBasisRelation@Context occurrences; it does not copy or own the compact. Pattern epistemes and U.MethodDescription epistemes supply clauses or declared premises; their described Methods remain distinct, while dated application Work and its separately governed result claims supply the reconciliation inputs.
• Defines: OntologyClaimSourceUseRelation@Context and OntologySourceUseConflictFinding@Context for bounded ontology-decision and reconciliation source use only.
• Coordinates with: A.10 for evidence use, G.11 for currentness, C.29 and direct formal patterns for formal semantics, C.2.1/E.17 for source epistemes and publications, and subject patterns for the receiving ontology claim.
• Preserves: current landed FPF decisions as default internal basis while allowing grounded, claim-specific reopen. It does not replace E.9.DA review or DRR discharge.
• Does not define: a universal source-authority kind, source role, prestige ranking, evidence relation, publication relation, or source-currentness relation.

#A.7.2:End

#Constructive-Premise Compact and Reasoning-Basis Use

Type: Architectural (A) Status: Stable Normativity: Normative

#Use this when

Use this pattern when reasoning, ontology analysis, choice, or reconciliation actually relies on a broad constructive claim and another person must be able to recover which claim, exact receiving claim or result, posture, scope, work occurrence, and interval carried that reliance.

The first useful move is to name the dated reasoning work, each exact claim-bearing result or receiving decision it is forming, the exact A7CP-* claim IDs used for that result, and whether each use is an adoptedPremise or conditionalAssumption. Leave the other compact claims latent.

Not this pattern when. Citation, publication, shared vocabulary, ordinary A.7 category-error repair, source currentness, or a domain/evidence problem that uses no compact claim in reasoning creates no relation occurrence. This support pattern is not a method, performer, work plan, catalogue-reading episode, or problem-facing result.

The primary reader is an author or reviewer who must make one load-bearing constructive premise use recoverable. The governed object is one ClaimUsedAsReasoningBasisRelation@Context occurrence and the exact compact claim content it cites.

#Problem frame

Dated work applying an FPF method can rely on broad claims such as “a publication does not create world-side obtaining” or “a MethodDescription episteme does not perform Work”. A U.MethodDescription episteme may state or cite one of those claims as a declared premise or branch condition for its described U.Method. ClaimUsedAsReasoningBasisRelation@Context instead records only the claim on which one actual inference, comparison, or choice in dated Work relies. Copying the claim into every method description makes it drift; leaving the dated reliance implicit hides whether a particular result used an adopted premise, a conditional branch, or no common claim at all.

The compact publishes twelve stable claim contents once. A U.MethodDescription episteme can declare an intrinsic premise or a branch condition for its described Method; a dated application records only the compact claims actually used in its reasoning. Ordinary Work therefore does not acquire a foundation checklist.

#Problem

Three conflations make premise use unreliable:

1. claim content is confused with the posture in which one work occurrence uses it;
2. citation or co-location is confused with actual reliance in reasoning; and
3. a support pattern is treated as a method that performs or governs the consuming work.

The result is either hidden premises or a copied catalogue that becomes a second ontology authority. Both failures obscure occurrence identity and reopen behavior.

#Forces

#Solution

#Publish the compact once

The compact carries these stable claim contents:

1. A7CP-01 Existence and obtaining. World-side obtaining is not created by a claim, database row, predicate, or publication merely representing it.
2. A7CP-02 Constructive settlement. When identity, constitution, dependence, or obtaining changes a consequence, name the construction or direct governing relation that grounds it; a reconstructible trace is not itself the world construction.
3. A7CP-03 Constitution and social objects. Constituting acts, admitted systems, and the relations they institute remain distinct from descriptions of those acts and relations.
4. A7CP-04 Epistemic openness and fallibility. Evidence and reliance may remain unresolved without turning unresolved evidence into a third world-side obtaining mode.
5. A7CP-05 Representation boundary. Descriptions, logical forms, database rows, graphs, and publications represent or carry claims under exact relations; their form does not prove the represented ontic.
6. A7CP-06 Agency and work attribution. A U.MethodDescription episteme describes an admitted U.Method; for a precise performed-Work claim, recover each exact actual performer through A.13 and let A.15.1 independently admit the dated U.Work. Only when the claim or its receiving use expressly consumes precise assignment-bound attribution does F.6 separately relate that Work to the same obtaining A.13 assignment; F.6 identifies neither the assignment nor the performer, neither the system-role kind nor the assignment acts, and missing or failed F.6 leaves the Work intact. A result follows only through its own separately established relation—for example, a production, operation-result, measurement, evaluation, decision, delivery, or acceptance relation—not from Work in general.
7. A7CP-07 Kind discipline. Use direct existing kinds and local admission before proposing a universal kind, root relation, or role-like surrogate.
8. A7CP-08 Scoped pluralism. Different source traditions or apparatuses may be useful for different receiving claims; compatibility is tested by consequences, not achieved through prestige hierarchy.
9. A7CP-09 Structure and wholeness. A description of structure is not the structure; not every construction is mereology, and C.13 alone defines constructional mereology.
10. A7CP-10 Time, identity, and currentness. World-side temporal qualification, occurrence identity, claim/publication currentness, and source supersession are separate questions.
11. A7CP-11 Subject-pattern separation. Capability, state, architecture, role, method, work, evidence, permission, and relation families retain their subject patterns even when an ontology method diagnoses a conflict among them.
12. A7CP-12 Formal projection non-reversal. CT2R and formalization may preserve, collapse, or omit structure. Logical validity or representation form does not reverse-infer a unique world construction.

The twelve IDs form a stable closed compact in this pattern. They are not steps, completeness criteria for every ontology use, or twelve intrinsic premise kinds.

#Record actual reasoning-basis use

Premise and assumption name postures of exact claim use, not disjoint claim kinds.

ClaimUsedAsReasoningBasisRelation@Context <: U.Relation

RelationSignature:
  BasisClaimSlot:
    SlotKind: BasisClaimSlot
    ValueKind: U.Episteme
    refMode: U.EpistemeRef
  ReasoningWorkSlot:
    SlotKind: ReasoningWorkSlot
    ValueKind: U.Work
    refMode: WorkRef
  ReceivingReasoningResultSlot:
    SlotKind: ReceivingReasoningResultSlot
    ValueKind: U.Episteme
    refMode: U.EpistemeRef

semanticDirection: BasisClaimSlot -> ReceivingReasoningResultSlot
  through the named ReasoningWorkSlot
ReasoningBasisPostureValue ::= adoptedPremise | conditionalAssumption

RelationOccurrenceQualifiers:
  basisClaimAddress: ClaimAddress
  posture: ReasoningBasisPostureValue
  reasoningUseScope?: U.ClaimScope
  modelUseStructureRef?: U.StructureRef

OccurrenceIdentity:
  <exact basis-claim edition and claim ID,
   exact reasoning-work occurrence,
   exact receiving-result edition,
   posture,
   reasoningUseScope when present,
   maximalContinuousRelianceInterval>

BasisClaimSlot is the exact claim-bearing episteme used, and basisClaimAddress is a [C.2.1](/generated/patterns/C.2.1) ClaimAddress selecting the exact claim inside that same edition by its intrinsic ClaimGraph identity. ReasoningWorkSlot is the dated reasoning, choice, ontology-analysis, or reconciliation U.Work that relies on it. ReceivingReasoningResultSlot is the claim, comparison, decision, or other claim-bearing result episteme whose content that Work forms or revises using the basis claim. If the practical result is world-side, use the direct result claim that bears on it; the world-side object retains its subject pattern. An admitted U.System performs the Work. If the case relies on an assignment, recover one actual occurrence of a separately declared U.SystemRoleAssignment species and the obtaining F.6 attribution for that exact Work-assignment pair; its holder must be the same System. The assignment's existence, holder, or interval does not establish that attribution, and the assignment neither supplies the System nor performs the Work. Claim episteme, described Method when one is used, Work occurrence, assignment occurrence, attribution, use posture, receiving result, and any world-side result remain distinct. The words “premise” and “assumption” are not relation participants.

The relation obtains during the maximal continuous interval in which the named work actually relies on the exact basis claim to form or revise the exact receiving result. Access, citation, publication, co-location, or use of the claim elsewhere in the same work is insufficient. reasoningUseScope appears only when this premise use is narrower than or otherwise differs from the receiving result's declared claim scope; modelUseStructureRef appears only when an independently selected BoundedModelUseStructure changes interpretation. Source currentness, evidence, publication, work method, and the receiving result's own governance remain with their subject patterns.

One occurrence is identified by the exact basis-claim edition and ID, reasoning-work occurrence, receiving-result edition, posture, optional narrower use scope, and maximal continuous reliance interval. If one work uses the same basis claim for two independent results, record two relation occurrences that share the work participant but name different receiving results; do not duplicate the work. A change to any identity value ends or splits only the affected result-specific occurrence.

#Keep posture and transition explicit

adoptedPremise means the named work presently uses the basis claim as accepted support for the exact receiving result. conditionalAssumption means the work uses it for that result only in a narrower model, scenario, proof, or branch with an explicit test, defeater, or reopen condition. Every conditional assumption actually used can function as a premise inside that bounded subargument; not every adopted premise is conditional. Neither posture changes the basis-claim episteme's intrinsic kind.

The same claim can have different postures in different work or for different receiving results of one work. A posture transition creates a later occurrence only for the exact receiving result on that relation edge. Reopen that result and its dependents; another result of the same work remains closed when its separate premise-use occurrence and posture did not change.

#Use the cheapest truthful path

1. Name the exact reasoning work and each exact receiving claim, decision, comparison, or other claim-bearing result it is forming.
2. For each receiving result, cite only the compact IDs that are load-bearing.
3. Record one relation occurrence per exact basis claim, receiving result, posture, and continuous reliance interval; reuse the same work reference across independent results.
4. Name a narrower U.ClaimScope or selected BoundedModelUseStructure only when it changes this premise use.
5. Keep evidence, currentness, source use, kind admission, subject construction, work method, and result governance with their subject patterns.
6. Stop when every load-bearing receiving result points to its exact premise-use occurrences. Do not inspect unused compact entries.

#Archetypal Grounding

Relation-occurrence repair. Ontology-analysis work splits one support relation into two occurrences after removal and reinstallation and returns SupportOccurrenceRepairDecision-17. That result relies on A7CP-01 and A7CP-10, so two reasoning-basis occurrences name the same work and receiving result but different basis claims. The other ten claims stay latent.

Role/chart reconciliation. Reconciliation work returns AssignmentConstitutionDecision-42, which distinguishes assignment constitution from a chart that evidences the assignment. Four result-specific relation occurrences connect that decision to A7CP-01, A7CP-03, A7CP-05, and A7CP-06. Source-use and evidence relations stay under their subject patterns.

Same-work selective reopen. SupportRepairWork-19 returns both WarrantyClaimRepair-19 and IncidentAttributionRepair-19. Each has its own relation occurrence to A7CP-10. The warranty result uses that claim as an adopted premise; the incident result uses it as a conditional assumption while a removal timestamp is disputed. Evidence that settles that timestamp changes the posture only on the incident-result edge, so IncidentAttributionRepair-19 reopens while the unchanged warranty-result edge leaves WarrantyClaimRepair-19 closed.

No compact use. Missing telemetry blocks a state claim while the relevant state and evidence distinctions are already clear. Work returns to measurement/evidence. No compact claim is load-bearing, so no reasoning-basis occurrence is created.

#Bias-Annotation

Lenses tested: Gov, Arch, Onto/Epist, Prag, Did. Scope: cross-pattern constructive premise support and actual reasoning-basis use.

The main biases are foundation maximalism, premise-kind inflation, and trace-by-citation. The mitigation is one compact publication source, exact claim IDs, two context-local postures, actual work participation, and a non-use rule that keeps ordinary reasoning cheap.

#Conformance Checklist

#Common Anti-Patterns and How to Avoid Them

#Consequences

The compact makes broad constructive reliance recoverable without enlarging current A.7 or creating copied foundation variants. Ordinary users pay nothing unless a claim is actually load-bearing. The cost is precise claim/work/posture identity in consequential reasoning; the benefit is one stable authoritative content source and bounded reopen.

#Rationale

Claim content and reasoning posture vary on different axes. Publishing the content once and recording use through a direct relation prevents both hidden premises and premise-kind inflation. Work participation makes the relation ontologically honest: an episteme can be used by reasoning work but cannot reason or act by itself.

Use only the premise the work actually relies on.

#SoTA-Echoing

The current-practice implication is practical: exact claim use and subject-pattern boundaries matter more than a large premise catalogue. The worked cases demonstrate when two, four, or zero compact claims are used.

#Relations

• Defines: the twelve A7CP-* constructive claim contents and ClaimUsedAsReasoningBasisRelation@Context, whose direct result-specific edge states that dated reasoning work used one exact basis claim to form or revise one exact receiving result episteme.
• Is consumed by: dated Work applying the Methods described by A.7.1 or A.7.2, which cites exact compact claims and exposes relation occurrences only for load-bearing actual reliance. The A.7.1 and A.7.2 U.MethodDescription epistemes may separately declare premises or branch conditions for their described Methods; neither MethodDescription nor Method is a participant of ClaimUsedAsReasoningBasisRelation@Context.
• Coordinates with: current A.7 for its existing strict distinctions without broadening its EntityOfConcern, first move, Solution, or cases.
• Preserves subject patternship in: A.10 and G.11 for evidence/currentness, E.24/E.24.UK for ontology admission, subject construction patterns for constructive settlement, and A.7.2 for ontology source-use relations.
• Does not define: a premise method, source authority, evidence relation, work plan, performer kind, common realism checklist, or universal foundation ontology.

#A.7.CP:End

#Universal Core Principle

Type: Kernel admission discipline pattern Status: Stable Normativity: Normative unless a section is explicitly informative

#Use This When

Use this pattern when a candidate durable U-kind is proposed as a kernel-level universal primitive rather than as a local concept, C.3 U.Kind, direct subject-pattern value, Concept-Set row, slot, relation, record, publication form, or dependent durable value.

What goes wrong if missed. A local domain noun enters the kernel as if it were universal, or a genuinely universal primitive is rejected because its domain projections use different words.

What this buys. Kernel admission becomes a falsifiable cross-domain claim: the candidate must keep the same abstract contribution across diverse domain families while losses and local differences stay visible.

Typical moments:

• a candidate U-kind is proposed because several domains use similar words;
• a local subject value starts being treated as universal because it is useful in one field;
• E.24.UK admits a durable U-kind candidate, and the remaining question is whether it belongs in the universal core;
• source or draft type wording claims kernel-level status and must be recovered into current U-kind governance.

Primary EntityOfConcern. The EntityOfConcern is the universal-core admission claim for one candidate U-kind.

First useful move. Apply E.24.UK first. If the candidate survives as a durable U-kind and claims kernel-level status, test whether it makes the same abstract contribution in at least three foundationally different domain families.

Not this pattern when.

• If the issue is C.3 typed claim quantification, use C.3 and C.3.1.
• If the issue is whether the public U.* spelling should survive at all, use E.24.UK.
• If the candidate can be expressed by composition, dependent value, slot relation, or direct subject pattern, use A.11 and the direct pattern before A.8.

#Problem Frame

FPF needs some universal primitives. It also needs to avoid turning a field's favorite vocabulary into the kernel. A word that works in software, finance, biology, or physics may still be local. A kernel-level U-kind must survive contact with different foundational domains without changing what kind of work it does in the model.

When source wording uses kind force for this admission question, recover it as kernel-level U-kind admission: E.24.UK decides durable U-kind admission basis, and A.8 tests universal-core claim force.

#Problem

Without A.8:

1. Parochial drift. A local domain concept enters the kernel and later cracks outside its home domain.
2. Kernel bloat. Near-universal values accumulate because each domain asks for its own core noun.
3. False universality. Search frequency, source prestige, or familiar spelling replaces cross-domain evidence.
4. C.3 confusion. A context-local U.Kind is mistaken for a universal FPF U-kind.

#Forces

#Solution

Use the three-domain falsification test only after E.24.UK has admitted the candidate as a durable U-kind candidate.

The candidate passes A.8 only when all four conditions hold:

1. Distinct domain families. At least three projections come from foundationally different domain families.
2. Same abstract contribution. Each projection shows the same kernel contribution, not merely a similar word.
3. Non-trivial diversity. Each projection adds a non-trivial signal or bridge evidence not subsumed by the other two.
4. Recorded losses. Differences, losses, and bridge risks are visible enough that readers can tell what is shared and what is local.

Use this compact record:

UniversalCoreProjection:
  CandidateUKind:
  UKindAdmissionResultRef: exact accepted E.24.UK output; follow it to the shared decision only when common inputs or decision mode are needed.
  DomainFamily:
  DomainTerm:
  LocalEoC:
  SameAbstractContribution:
  DifferenceOrLoss:
  EvidenceRef:

Three records are the minimum evidence. They are not an analogy. They are a falsification attempt: if one projection changes the candidate's abstract contribution, the candidate is not universal in the proposed form.

#Archetypal Grounding - Diversity Evidence

For busy readers: one idea, three worlds. A candidate that cannot keep the same abstract contribution across three different domain families should stay local, dependent, or constrained by a subject-specific predicate located through its subject pattern.

These rows are grounding examples, not automatic admissions. The projection record still needs an E.24.UK basis and must state losses and bridge risks.

When diversity evidence is load-bearing, record domain-family coverage, non-trivial difference, and bridge evidence. Quality-diversity telemetry such as Diversity_P or IlluminationSummary can support the projection record only through its governing C.17, C.19, or direct pattern; it is not a standalone gate.

#Bias-Annotation

A.8 intentionally biases against kernel growth by name familiarity. This is useful because every admitted universal primitive raises the cost of FPF reasoning. The counter-bias is the three-domain falsification test: do not reject a candidate merely because domains spell it differently when the same abstract contribution is visible and losses are recorded.

#Conformance Checklist

#Common Anti-Patterns and How to Avoid Them

#Consequences

A passed A.8 test strengthens the case for kernel placement but does not bypass E.24.UK admission predicates, A.11 parsimony, or the exact subject assertion. A failed test is still useful: it tells the project where to keep the candidate local, dependent, or constrained by a subject-specific predicate. The cost is evidence work across at least three domain families.

#Rationale

Universal core primitives are expensive because every downstream pattern can rely on them. A.8 therefore treats universality as a claim about repeated abstract contribution across different foundational domains, not as a claim about lexical frequency, popularity, or early convenience.

#SoTA-Echoing

The pattern adapts three current practice lines. Ontology engineering distinguishes upper-level commitments from domain ontology terms; A.8 turns that distinction into a falsification test for FPF U-kinds. Cross-domain modeling practice uses multiple heterogeneous cases to test whether a construct travels; A.8 records those projections with losses rather than treating analogy as proof. Quality-diversity practice helps surface non-trivial diversity, but A.8 keeps telemetry as evidence for projection records, not as an admission gate.

#Relations

• Builds on: E.24.UK, A.11, C.3, C.3.1, F.8, and F.18.
• Coordinates with: Concept-Set and bridge patterns when domain-family projections require cross-context naming or translation.
• Does not replace: E.24.UK for U-kind admission, A.11 for parsimony, or C.3 for typed claim quantification.

#A.8:End

#Cross‑Scale Consistency (C‑3)

“The logic of a bolt must still be the logic of the bridge.”

#Context

FPF models reality as a nested holarchy: parts → assemblies → systems → supra‑systems; axioms → lemmas → theorems → paradigms. Designers and analysts must zoom freely without logical whiplash. Classical mereology and modern renormalisation theory both warn: if rules mutate across scales, predictions and audits collapse. FPF therefore mandates a single, scale‑invariant Standard.

#Problem

These pathologies derail safety cases and budget decisions across disciplines.

#Forces

#Solution — Invariant Quintet + Meta‑Holon Transition

#Invariant Quintet

Any aggregation operator Γ that claims FPF conformance MUST preserve these five invariants :

Mnemonic: S‑O‑L‑I‑D (Same - Order‑free - Location‑free - Inferior cap - Don’t‑regress).

Inter‑Layer Standard note When holons are composed as a Layered‑Control stack, each Planner ↔ Regulator pair MUST publish an inter‑layer Standard: {referenceSignal, guaranteedTrackingError, cycleTime}. Matni 2024 (https://arxiv.org/abs/2401.15185) prove such Standards satisfy COMM + LOC invariants, giving a constructive instance of the Quintet.

#Meta‑Holon Transition (MHT)

If empirical data show a true violation (e.g., redundancy raises WLNK limit), the modeller declares an MHT: the collection becomes a new holon at a new scale, and the quintet applies anew at that scale.

#Archetypal Grounding

#Conformance Checklist

#Consequences

#Rationale

Post‑2015 evidence across domains

• Physics ‑ Renormalisation coherence echoes IDEM, COMM, LOC.
• Distributed data platforms rely on COMM + LOC for deterministic aggregations.
• Safety engineering ‑ Fault‑tree analyses hinge on WLNK; aviation failures (2018‑24) confirm its necessity.
• Lean improvement ‑ MONO underpins Kaizen: fix a bottleneck, never worsen the plant.

Packaging these insights as one memorisable quintet → Cognitive Elegance with formal bite.

#Relations

#Known Uses (2018‑2025)

• Spacecraft avionics ‑ Applying WLNK exposed a sub‑grade connector, saving a $40 M launch window.
• Global vaccine meta‑reviews ‑ COMM + LOC let five epidemiology teams merge data independently; results converged within 0.1 % effect size.
• Distributed ML training ‑ MONO guaranteed optimiser swaps never reduced accuracy, cutting iteration time by 20 %.

#Open Questions for expert panel

1. Order‑sensitive physics – Should quantum‑circuit folds live in a Extention Patterns with a relaxed invariant set?
2. Synergistic redundancy – Can WLNK be reframed using an “effective minimum” when true redundancy lifts the floor?
3. Didactic tooling – Which visual cues best alert non‑formal audiences to an approaching Meta‑Holon Transition?
4. Layer depth — In an LCA (layered control architectures, https://arxiv.org/abs/2401.15185) stack every Planner is external to its Regulator; should FPF limit the number of nested layers, or is indefinite chaining acceptable?

#A.9:End

#Evidence Graph Referring: Claim-Bound Evidence and Provenance Graph

Type: Kernel pattern Status: Stable Normativity: Normative

#Problem frame

Use this pattern when a source, carrier, result episteme, credential, dashboard, provenance label, generated explanation, model card, or review note is being relied on for a named claim or bounded action and the source-to-use account is still implicit.

Primary EntityOfConcern. The live object is the exact relied-on claim and bounded use. A.10 builds a descriptive evidence-provenance path that represents the independently established sources, carriers, work, result epistemes, provenance relations, currentness, and later-use relations needed to judge that use. The path is not a new world-side relation and its edges establish none of the facts they cite.

First useful move. Write: “Claim episteme E is being relied on for bounded use U; E states local result R; the cited sources, carriers, and direct relations are S; currentness is T; the bounded A.10 disposition is D.” Add a dated U.Work occurrence only when that Work is itself a current claim. If the account says that Work returned, produced, or obtained a value, name the exact A.6.1 application binding, one local A.15.PROD claim, or a direct subject relation under its own pattern; otherwise keep the Work and value as separate facts. Mark any missing rule or relation as a gap.

What goes wrong if missed. Carrier presence becomes truth, provenance becomes approval, a result record becomes performed work, MethodDescription becomes a run trace, a graph edge becomes an obtaining relation, and a currentness or assurance decision is inferred from display styling.

What this buys. A source-to-use account that can be replayed, contested, refreshed, narrowed, or handed to the pattern that defines or tests an additional claim, while keeping the claim, carrier, performed work, local result, result episteme, provenance, currentness, reliance, assurance, and action distinct.

Not this pattern when. A.10 does not establish measurement, formal, causal, diagnostic, conformance, comparison, selection, acceptance, gate, permission, commitment, Work, or decision results. It does not establish representation correspondences. Use the pattern that defines or tests each result, A.15.1 and A.6.1 for performed Work and actual bindings, C.2.1 for the result episteme, G.11 for currentness, C.29 for representation, and B.3 only when an actual named assurance claim is current.

Use A.2.4 first when only the first evidence-use or status-use classification of an episteme is at issue. Enter A.10 when carrier identity, source recovery, provenance, currentness, rival explanations, or bounded reliance must remain replayable.

Here path means a path in a descriptive evidence/provenance graph, never a route of action or a universal evidence relation.

#Problem

Source-backed reasoning fails in recurring ways:

1. the relied-on claim is not named;
2. a carrier or publication face is substituted for the claim it represents;
3. a method description, plan, signature, or stored reference is substituted for actual work and bindings;
4. a local domain result is replaced by a generic evidence or result field;
5. provenance, currentness, reliance, assurance, and authorization are collapsed; or
6. a graph edge is asserted before the direct source, work, production, representation, participation, or use relation is known to obtain.

The practical effect is false authority and unreplayable decisions: a badge looks like permission, a dashboard looks like a gate decision, or a model output looks like an accepted conclusion.

#Forces

• Minimality vs consequence. Orientation needs a small path; material reliance needs the exact fields that change the decision.
• Carrier identity vs claim content. The same content can appear in several carriers and editions; a carrier can be authentic while the claim is false or stale.
• Reusable method vs performed work. A method describes a repeatable way. Ordinary reading, orientation, or reliance can remain ordinary; a claim about performed U.Work requires the dated occurrence and exact bindings.
• Provenance vs result establishment. A.10 must make a result traceable without establishing the result itself.
• Graph convenience vs ontic discipline. A graph can represent many relations compactly but cannot make them obtain.
• Contestability vs confidentiality. Reliance must be challengeable while sensitive carriers may require scoped, redacted, hashed, or access-controlled views.

#Solution — recover exact objects before drawing the path

#Start with the relied-on claim

Name the exact C.2.1 episteme whose content is being relied on. Its ClaimGraph states one local result or proposition, subject, interpretation basis, polarity or status when current, and uncertainty or qualification when relevant. The local result must come from the pattern that defines or tests it: C.16 for measurement, C.28 for causal support, A.19 for comparison or selection, G.4 for an acceptance-clause application, A.21 for a gate decision, C.11 for a decision, and the applicable formal, diagnostic, conformance, identity, permission, or commitment pattern. When role appears in a technical result, use E.10.ROLE to select the exact local system-role-kind classification, U.SystemRoleAssignment occurrence or state, relation among system-role kinds, declaration, participation, interface, or representation claim before citing its governor.

A carrier, citation, provenance entry, or A.10 classification does not constitute the result episteme or the domain result. When their identity or inception is live, use C.2.1 and A.15.PROD respectively.

#Ground source, carrier, publication, and representation

Recover the selected source episteme and its edition and claim content. When availability, form, or carrier matters, separately recover the EpistemePublicationRelation occurrence, publication form, carrier, or face involved, together with any copy, extraction, or transformation between source and use. Use E.17 for publication and C.29 for representation correspondences. The descriptive graph points outward to those independently established objects and relations.

Carrier authenticity, integrity, or provenance may support only its named origin, history, build, or transformation claim. It does not imply truth, safety, approval, release, permission, assurance, or work occurrence.

#Separate method, work, participants, and local result

U.MethodDescription is an episteme about one exact U.Method. It may state generic participants, parameters, effects, and operating conditions. It has no actual-participant slots and no intrinsic design-time intention, proof criterion, test criterion, or claim that work occurred.

Source production, measurement, verification, interpretation, transformation, query, review, publication, or later reliance may be described ordinarily. When the current claim says that one of these is a dated U.Work occurrence, first recover each actual performer's A.13 core and independently admit the occurrence through A.15.1 from its performance history, enacted Method, extent, and containing-System relation. Add F.6 afterward only when the evidence account also needs precise assignment-bound attribution. A short account may omit an assignment identifier unused by the receiving claim; when attribution is consumed, every required assignment and F.6 fact remains recoverable. Affected or evaluated referents, resources, and actual participants enter only through direct subject relations or A.6.1 operation-application bindings. Capability, authority, and responsibility remain separate predicates. A compatible signature, plan, description, log schema, or graph node establishes none of those bindings.

For every cited result, name the pattern that defines or tests it and its C.2.1 result episteme separately. The provenance path may represent exact Work, participants, entities, domain results, result epistemes, and outcomes only after their direct relations are established. Relate Work to a returned or produced value only through an exact A.6.1 application binding, one exact local A.15.PROD claim, or a direct subject predicate under its own pattern; otherwise show the two facts separately and return the reason-specific non-assertability result if that connection is needed.

#Build a descriptive evidence-provenance path

The minimum A.10 path records only what the bounded use needs:

Graph nodes retain their admitted kinds. Each edge cites one independently established direct relation; no generic evidences, verifiedBy, validatedBy, measuredBy, producedByWork, or criterion-participant relation is minted as a fallback. A project may label display edges for navigation, but the label has no ontic force.

#Classify bounded reliance

The canonical local RelianceDisposition member set is exactly: pass, degrade, abstain, reopen, evidence-needed, assurance-needed, and blocked-current-use. pass supports only the exact bounded use; degrade supports only the named narrower or reversible use. assurance-needed says that A.10 alone cannot support the attempted use because a direct domain rule or receiving decision requires a separately stated assurance claim. It creates no assurance claim and does not open B.3 until that claim is current. No disposition is claim truth, CV.Status, gate decision, selector outcome, approval, permission, release, assurance, or Work authorization.

When an actual named assurance claim is current, use B.3 for that assurance question. A.10 continues to supply the exact source and provenance paths but does not issue the assurance result. Consequential evidence use without such a claim stays with the direct safety, access, status, gate, permission, release, responsibility, or controlled-action pattern.

#Route unlike exploratory inputs without changing their kind

When an observation, objective, former cue, novelty characterization, or similarly interesting item is proposed as a premise for an exploratory or creative move, recover the item under its direct owner before applying this bounded reliance classification. Do not rename every item signal or cue, and do not create a second premise-disposition vocabulary.

The composition produces only the direct source result, one existing RelianceDisposition when bounded reliance is current, and one later ChoiceResult. If the source claim is already qualified and the current C.11 record can use it directly, stop; no intermediate premise record is required.

#Currentness, actual use, and graph limits

Source availability and source currentness are distinct. Record issue/effective windows, supersession, revocation, source-order rules, and the G.11 currentness result when a use depends on them.

Actual reliance requires one exact premise, reference, decision-use, operation-argument, or other direct relation to the result episteme. When that reliance is also claimed as dated U.Work, recover the Work independently. Storage, indexing, citation, graph membership, visibility, or co-location establishes neither reliance nor performed Work.

Part-whole, temporal, production, publication, representation, provenance, participation, and reliance relations must each be established separately. The A.10 graph may cite them together for replay but never substitutes one for another.

#Authority-reliance use of ordinary A.10 evidence-provenance paths

Use this subsection when an authority-looking carrier is being relied on. The A.10 path represents one named claim, its exact sources and direct relations, and one bounded use; it is not an authority relation. If the Work occurrence, gate decision, speech act, commitment, permission, exact system-role assignment, assignment-state assertion, or other required relation already exists in a project-side source, recover that object by value and let the graph cite it.

A10-lite is enough for source-finding, orientation, learning, and bounded reversible probes:

Minimum evidence-provenance path for routine reliance:

Expanded fields are collected only insofar as they decide the current reliance question. Evidence depth follows consequence severity, reuse, contestability, cross-context movement, and the evidence relation required for the attempted claim. Do not expand a source-finding note into a full evidence dossier, and do not collect every expanded field merely because a carrier is copied, generated, credential-like, provenance-like, or cross-context.

Adversarial misuse guard. Do not let carrier authenticity, provenance, copied approval, generated summary, stale screenshot, credential status view, or dashboard export convert into claim truth or currentness. Treat each as a rival explanation to test against the exact issuer, publication, registration, status-source, source-maintenance, trust, acceptance, or currentness predicate actually used; any source-side Work and its attribution; the time window; and the relying context. If the needed predicate has no governor, return that A.6.RCD gap rather than calling it support.

Data-minimization and privacy boundary. Preserve the minimum source, provenance, and direct-relation account sufficient for the intended use. Use redacted, hashed, scoped, or access-controlled carrier refs when raw material would expose personal identity, access tokens, cryptographic proof payloads, tenant identifiers, security logs, incident details, internal release metadata, audit trails, privileged reviewer identities, sensitive model provenance, or sensitive data provenance. Redaction creates no source relation; it must preserve enough recoverability for the relying context.

Case repairs:

If the evidence-provenance path is incomplete, A.10 reports the missing source, carrier, work, rule for the cited result, direct relation, or G.11 currentness fact and narrows or blocks only the attempted use. Possible dispositions include source-finding only, reopen original carrier, request issuer or status verification, refresh the source query, mark stale or contested, narrow the attempted P2W class or reliance claim, proceed only with a reversible local probe under an explicit work plan, or block the unsupported use.

Missing source-relation repair assignment. If the relying actor cannot recover or verify the source relation, name the admitted System selected by an independently obtaining project-side repair-responsibility relation and assign only prospective repair Work. The relevant issuer or performer, exact verifier system-role-assignment occurrence when one is current, status-source relation, evidence-producing Work and System, gate-decision source relation, system-role-assignment source relation, status register entry, boundary claim relation, or source-currentness relation remains a separate fact; none is a responsibility relation by form. If the corpus has no direct predicate that selects the repair System for this case, record the exact A.6.RCD missing governor. The A.10 result names the missing source relation or source-bearing record and blocked use rather than making the relying actor reconstruct a relation they cannot issue or verify.

Repeated missing-source-relation indicator. If the same visible carrier family repeatedly returns stale, contested, missing-source-relation, or no-currentness A.10 results, record a source-relation repair action: instrument the source relation, expose the carrier field that carries the source-bearing relation, expose decision-log refs, add currentness checks and status checks, preserve claim-bound source relations for generated or copied outputs, require credential views to show status windows and currentness windows, require model documentation and data documentation to expose intended-use and evaluation-condition fields, or require provenance labels and attestation labels to name their bounded claim type. Repetition is an indicator that the source relation or display needs repair; it is not a reason to make each acting user rebuild the evidence-provenance path manually.

Display guidance for evidence and currentness: an evidence or status display should show the claim or effect, evidence carrier, the exact issuer, publication, registration, status-source, source-maintenance, trust, acceptance, or currentness predicate it uses, reference or link named by value, time window, freshness, relying context, and unsupported Work use, reliance use, claim, or effect. A display that can only show source availability should say so; it must not imply approval, permission, gate passage, Work occurrence, or assurance.

Incident-learning fields for evidence and currentness overread: visible carrier or publication face, intended claim or effect, missing evidence-provenance field, evidence carrier named by value, exact source-side predicate actually used, ordinary method trace or admitted Work trace, and needed time relation; rival explanation; current safe disposition; and the smallest upstream repair to instrumentation, selected source U.Episteme, exact publication occurrence when availability matters, changed publication form or carrier, issuer, registration, status-source, source-maintenance, trust, acceptance, or currentness relation, claim-bound source relation, credential view, model or data documentation, or provenance or attestation label.

Contestability and redress relation: when an evidence-provenance path or source-currentness relation affects person or team status, access, responsibility, a compliance relation, or a release decision, the A.10 result names the disputed claim, evidence carrier, affected use or harm, available challenge, review, redress, communication, source, publication, register, access, or contact relation, allowed evidence or argument, possible disposition change, outcome route, reopen trigger, and safe interim disposition. Source exposure remains independent of who may later perform review or repair Work. Name a responsibility, allocation, commitment, permission, or authority relation—or its exact missing governor—only when assigning that future Work; its absence does not close the challenge.

Positive repaired evidence-use statement. When the source account is complete, write the smallest bounded statement: named relied-on claim; carrier and source; direct provenance, citation, and currentness relations; ordinary bounded use; RelianceDisposition; unsupported attempted use; and reopen condition. Add producing or interpreting U.Work, each actual performer's A.13 core, independent A.15.1 admission, Method, actual bindings, and later Work only when those facts are current. Add F.6 afterward only when the receiving account needs precise assignment-bound attribution. A claimed Work-to-value link needs an exact A.6.1 application binding, one local A.15.PROD claim, or a direct subject predicate under its own pattern. Add authority or responsibility only when an exact relation is independently required by the use. A short Work statement may omit an unused assignment identifier only when every relation it consumes remains recoverable; an assignment is never the authority or responsibility result.

What this does not authorize: A.10 does not approve, authorize, pass a gate, release, create permission or commitment, classify a local system-role kind, establish a U.SystemRoleAssignment occurrence or state, establish a relation among system-role kinds, record Work, establish a domain result, assert a representation correspondence, or raise assurance. It supplies source recovery, provenance, and bounded reliance for the exact neighboring objects named by value.

#Local evidence-use classifier and RelianceDisposition for source-bearing carrier or display reliance

Use this subsection when a visible carrier, publication face, selected source U.Episteme ref, exact EpistemePublicationRelation occurrence ref when availability is material, source relation ref, or display is being relied on for a named claim or act. First recover the claim kind, the pattern or source rule that defines or tests the claim, the source/provenance path, and the bounded use. Broad words such as source, metric, confidence, conformant, safe, ready, certified, approval, or permission are recovery prompts, not relation names.

This is a local reliance-use classifier, not a Core evidence-kind ontology. Use only the row that decides the attempted use. The path represents exact direct relations and the RelianceDisposition records one bounded A.10 judgment; neither becomes a general evidence or authority relation. Affordability card: orientation or source-finding remains a cue and stops here; bounded reliance states one evidence use, unsupported attempted use, window, and reopen condition. If a direct domain rule requires assurance, state the exact assurance claim and then use B.3. Plain wording remains ordinary unless it changes one of the named source, evidence, gate, assurance, Work, decision, or control claims.

Cheap stop: if a bounded claim, current carrier, evidence-provenance path, window, bounded evidence use, unsupported attempted use, and reopen trigger are present, and there is no actual assurance claim, gate relation, Work relation, control-bearing relation, or release relation, stay in A.10. Do not open B.3, A.21, B.2.5, or a broad evidence pack merely because the carrier or display looks official, quantitative, generated, credentialed, or safety-related.

Common wrong first classification: a visible carrier, selected source U.Episteme ref, publication-form or carrier ref, exact EpistemePublicationRelation occurrence ref, source relation ref, or display is approval, permission, safety, or readiness. First honest entry: recover the A.10 evidence-provenance path for one bounded claim or use; approval, permission, safety, readiness, gate passage, and work authority must be established separately under the pattern that defines or tests each claim.

Plain disposition palette: RelianceDisposition=pass means proceed only inside the bounded evidence use; degrade means use only a narrower or reversible version; abstain means do not decide yet; reopen means a changed or contested evidence relation defeated the previous classification; evidence-needed names missing evidence at the decision point; assurance-needed says a separately stated assurance claim is required before this attempted use can proceed; blocked-current-use blocks the attempt until its evidence-provenance path or source relation changes.

For A.10 use, RelianceDisposition is a local disposition over the evidence-provenance path and the bounded reliance use. Outside a table column already headed RelianceDisposition, write the qualified form RelianceDisposition=... and bind it to the named attempted use, currentness and window when relevant, bounded evidence use, unsupported attempted use, and reopen or stop condition; it is not CV.Status, GateDecision, selector result, or ProblemCard@Context state.

Observed-effect or consequence evidence may be used only for what happened or is credibly recorded. If the attempted use says the source caused, prevented, would have changed, or is responsible for that effect, leave ordinary A.10 reliance and open C.28 plus any relevant evidence, work, or assurance relation.

If a proxy marker, benchmark, confidence value, dashboard metric, or score becomes the primary driver for action, release, resource allocation, people status, team status, or P2W priority, check whether the claim being made also raises an E.13 proxy-to-objective question. Do not open E.13 for every metric; open it only when the proxy is being used as the target or decision driver.

If publication or observation of a cue changes the represented situation or represented source condition, recover the probe-coupled boundary before treating the cue as passive evidence. This sentence does not import quantum-like vocabulary; it only prevents passive-evidence overread for dashboards, warnings, labels, and public status displays.

Minimum contest relation with possible redress: a contest relation exists when the affected party can identify the disputed claim or source, affected use or harm, an available challenge, review, redress, communication, source, publication, register, access, or contact relation, evidence or argument allowed in challenge, possible disposition change, outcome route, and reopen trigger. A system-role label, assignment, feedback channel, complaint form, or appeal label without those recoverable values is not enough to change the disposition. Responsibility for future review Work is a separate claim.

Affected-party contestable minimum: even when raw evidence stays restricted, the contesting party must be able to see enough of the claim, source class, disposition, affected use, available challenge or contact route, and allowed challenge evidence to challenge the result. Privacy, security, or privilege can narrow disclosure; they cannot erase the challengeable minimum while still claiming contest or redress.

False-negative reliance guard: a blocked, abstained, or evidence-needed use is not final if challenge evidence, missing affected-party evidence, changed source relation, changed selected source U.Episteme edition, changed EpistemePublicationRelation occurrence when availability is material, changed publication form, changed evidence carrier, changed representation, or redress can materially change the disposition. If refusal is based on missing evidence, name the missing evidence kind and decision point rather than closing the dispute by vagueness.

Sensitive evidence boundary: use scoped, hashed, redacted, or access-controlled evidence refs when raw carriers would expose personal data, secrets, tokens, privileged logs, tenant identifiers, incident details, security-sensitive traces, or unnecessary identities. A redacted path must still preserve enough recoverability for the relied-on claim, disposition, and contest relation.

Worked source-overread slices:

#Route a Changed Claim Across Several Actual Receiving Uses

Use A.10.1 when a later or replacement source may materially change a claim and the receiving uses must still be found across a bounded frame or closed across several actual uses. A.10 continues to govern each exact one-use source-to-use account, direct-use relation, and RelianceDisposition. Applying A.10.1 bounds the receiving-use search frame, states source-outward and receiver-oriented coverage and gaps, classifies found candidates as depends, mentions only, or unresolved, and prepares only action-changing depends branches for application of their direct subject-pattern guidance.

If one already-known bounded reliance use is the whole question, apply A.10 and the direct subject guidance. A citation, carrier, declared edge, or graph-reachable node does not become affected merely because the source changed. The completed A.10.1 account cites each independently obtained subject result afterward; it neither replaces that result nor changes A.10's disposition set.

#Causal support in evidence-provenance paths

An A.10 path used for a causal claim cites the exact C.28 components it actually carries; it does not compress them into one alternative-valued “support basis” or copy C.28's field list.

causalSupportComponentRefs?: CausalSupportComponentRefs
causalUseSupportResultRef?: CausalUseSupportResultRef

CausalSupportComponentRefs remains defined only by C.28. A.10's ordinary evidence-provenance path still identifies the exact source, carrier, Work or data, provenance relations, and bounded use required by this pattern. Inside the C.28 contract, cite only the components the causal claim actually relies on. When C.28 admits another specialist component, A.10 can cite it through that contract without defining a second schema.

Examples:

• an observational cohort path cites the observation and measurement Work plus observationalOrNaturalBehaviorData; an intervention-effect statement still needs a C.28 identification or design result;
• a randomized estimate path cites assignment and Work evidence, its identification or design result, estimate, uncertainty, and limits;
• a prospective counterfactual-sampling path may cite the realizability result with its decision Method, construction, bound, or obstruction, but claims no performed sampling or data;
• a performed counterfactual-sampling path cites dated sampling Work, attribution, and the resulting sample or data; only that complete path may support realizedCounterfactualSamplingData;
• a simulation path cites model output, assumptions, validation, and bounded model use; it does not become realized or interventional evidence by relabeling;
• a target-trial emulation path cites its TargetTrialMappingResult, including the observational source, protocol-to-data mappings, gaps, residual-confounding assessment, and sensitivity mappings; reporting completeness alone establishes neither identification nor low bias;
• an off-policy or causal-RL path cites its exact OffPolicyCausalEvaluationResult with the question, behaviour and evaluation policies, overlap check, supported and unsupported use, and reopen condition. It also cites optional details about history or horizon, confounding, changed endpoints or transport, the estimator, and uncertainty only when they change what the path supports, where that support came from, whether it is current, its bounded use, or when it reopens;
• a causal-representation path cites its exact CausalVariableRepresentationRecord with the question, source representation, selection or abstraction Method, representation assumptions, intervention-validity result, supported and unsupported use, and reopen condition. It also cites optional invariance, fidelity, query-preservation, uncertainty, or shift-limit results only when they change what the path supports, where that support came from, whether it is current, its bounded use, or when it reopens;
• a transport path cites every changed endpoint, assumptions, overlap evidence, formula or comparator, uncertainty or unresolved assumptions, and bounded use carried by its transportability result; and
• an observationally identified estimate cites both the evidence path and separate identification and estimate results.

What changes in practice: the path exposes where every relied-on component came from and may cite the C.28 support-result episteme. A.10 creates none of the C.28 components, the causal verdict, or downstream authority by carrying their refs.

#Archetypal Grounding

Runtime acceptance from a measurement result. C.16 dated measurement work obtains a pressure measurement result with uncertainty under a named model and calibration; a distinct C.2.1 episteme states it. If the claim that this Work first constituted that episteme is current, A.15.PROD recovers one local entity-inception claim. Separate evaluation work applies the declared G.4 pressure clause through A.6.1 bindings and obtains unknown; another C.2.1 episteme states that verdict. A.10 records the source publications, calibration and measurement work, result episteme, evaluation work, clause declaration, exact bindings, provenance, currentness, and rival explanation. Later C.11 decision work uses the verdict episteme as a premise and defers. No ledger edge establishes measurement, verdict, decision, or use.

Meta-analysis. Source study publications, datasets, analysis code, inclusion work, statistical method, and synthesis work are recovered by their direct relations. The statistical method and result relation establish the pooled estimate and uncertainty; its C.2.1 episteme is the relied-on claim. A.10 records source identity, transformations, coverage, provenance, currentness, and the bounded clinical or policy use, not a generic validatedBy relation.

Credential display. A credential view can support credential currentness only when it names the exact issuer or trust-root object and relation, holder binding, verifier, exact status source or register relation, revocation, and window. Permission, commitment, an exact system-role-assignment occurrence, status assertion, entry predicate, and gate passage remain with A.2.8.PER, A.2.8, A.2.9, A.2.1, A.6.B, and A.21 as applicable. Display presence creates none of them.

#Bias-Annotation

A.10 corrects carrier-authority bias and graph-authority bias. A polished badge, attestation, dashboard, generated explanation, or provenance mark can make an unsupported claim look settled; a tidy graph can make an ungrounded edge look like an obtaining relation. The repair is to recover the claim, source, carrier, work, local result, pattern or source rule that establishes it, result episteme, direct relations, currentness, bounded use, rival explanation, and disposition. More impressive paperwork is not a substitute.

#Conformance Checklist

1. Claim: the exact relied-on C.2.1 episteme and proposition/local result are named.
2. Result rule: every measurement, formal, causal, diagnostic, conformance, comparison, selection, acceptance, gate, permission, commitment, system-role-kind classification, system-role-assignment occurrence or state, relation among system-role kinds, or decision result identifies the pattern that defines or tests it; any other technical role use is first routed through E.10.ROLE.
3. Carrier/source: the selected source episteme and edition, any material publication occurrence, form, carrier, or face, the copy/transform chain, and direct provenance or citation relations are recoverable.
4. Work: whenever production, interpretation, transformation, evaluation, or reliance is asserted as dated U.Work, point to its basis: A.13 first, independent A.15.1 Work admission second, and F.6 afterward only for precise assignment-bound attribution. Add direct relations, A.6.1 bindings, and resource-use facts only when the receiving claim uses them. Ordinary source-finding action need not be admitted as U.Work.
5. MethodDescription boundary: the description contains only generic method claims; it supplies no actual participants, occurrence, use, proof/test event, or result.
6. Result boundary: domain result, result episteme, carrier, provenance entry, outcome, and later action remain distinct.
7. Graph boundary: every asserted edge names an independently established direct relation; no edge establishes work, participation, production, result, currentness, reliance, or representation by graph membership.
8. Time/currentness: edition, window, supersession, revocation, source order, and G.11 result are explicit when they affect use.
9. Reliance: bounded use, unsupported attempted use, local RelianceDisposition, rival explanation, and reopen trigger are present; B.3 opens only when an actual named assurance claim is current.
10. Contest/privacy: the affected party can challenge the claim and disposition, while sensitive carrier access is minimized without erasing recoverability.

#Common Anti-Patterns and How to Avoid Them

• Carrier as truth. Recover the claim and direct source relation; authenticity or availability is not truth.
• MethodDescription as intent or trace. Recover generic method claims separately from the dated work and actual bindings.
• Generic result field. Name the domain result, the pattern that defines or tests it, and the distinct C.2.1 episteme.
• Edge as fact. Establish the direct relation first; then let the graph represent or cite it.
• Provenance as assurance or permission. Enter B.3, A.2.8.PER, A.21, or the pattern that defines or tests the additional claim only when that claim is live.
• Citation as actual use. Ground the later work and exact premise/reference/argument relation.
• Full dossier by default. Collect only fields that decide the bounded use, consequence, contestability, and reopen condition.

#Consequences

Benefits. Reliance becomes replayable without turning A.10 into an authority over the results it cites. The same path can expose stale sources, hidden transformations, ungrounded work, incompatible currentness, or an unsupported lift from provenance to action.

Trade-offs. Subject-pattern recovery takes more effort than a single evidence edge. The gain is that later users can challenge exactly the claim, work fact, source relation, currentness result, or reliance boundary that failed.

Failure containment. Missing source, work, direct binding, rule for a cited result, currentness, or use relation blocks or narrows only the affected reliance use. It does not authorize a universal evidence or result relation.

#Rationale

Evidence use is a relation-specific claim about why one later use may rely on one episteme. Provenance records make the source history recoverable; they do not create the source facts, local result, truth, work, or use. Keeping the descriptive graph outward-facing keeps each cited result with the rule that establishes it while still making complex source chains inspectable.

#SoTA-Echoing

Source qualification was checked against the publishers' current surfaces on 2026-07-30. It remains qualified through 2027-07-30 unless a latest specification, Recommendation, tagged framework release, status mechanism, or adopted documentation baseline changes earlier. Each source changes only the bounded A.10 locus named below; lineage and popular comparators not listed here are non-governing.

The current source decisions deliberately do not import a credential, attestation, documentation, or provenance ontology as A.10 authority. Source refresh replays the named rule, case, and checklist rows first and widens only if that local replay exposes a direct contradiction.

#Relations

• Builds on: C.2.1 for claim and result epistemes; E.17 for publication and carriers; A.13 for every precise performer's local core, A.15.1 for independent dated Work admission, and F.6 only for a current precise assignment-bound attribution; A.6.1 for actual operation bindings; A.15.PROD when entity inception or production completion is current; and E.10.ROLE plus the selected A.2-family pattern for any technical role claim.
• Coordinates with: A.2.4 for first-use evidence/status classification; G.11 for currentness; C.29 for representation; B.3 for assurance; C.16 for measurement; C.28 for causal use; A.19 for comparison/selection; G.4 for acceptance declarations and applications; C.11 and A.21 for decision/gate results.
• Constrains: provenance and reliance descriptions only. A.10 does not create another pattern's result, occurrence, participation, representation, currentness, assurance, permission, commitment, gate, or decision.

#Older source text interpretation and neighboring-pattern notes

Treat legacy names such as manifest, creator, observer, symbol register, SCR, RSCR, MIC, verifiedBy, validatedBy, or evidence path as recovery prompts, not current relation names.

• A manifest or source register is a carrier/publication or provenance description; recover the exact source, edition, claim, and direct relations it represents.
• A creator, observer, producer, verifier, or maintainer participates as an admitted System only when the direct participation relation obtains. If dated Work is asserted, recover every precise performer's A.13 core and independently admit the Work under A.15.1. Add F.6 afterward only when precise assignment-bound attribution is current. Name any exact direct relation or A.6.1 binding used by the claim separately. Those labels and assignments supply neither participation, authority, nor responsibility.
• A method-instantiation note is not work. Recover the exact U.Method, generic MethodDescription claims, dated occurrence, enactment, ordering, participants, and result separately.
• A work result, measurement result, validation result, or verification result label requires the exact domain result and a separate C.2.1 episteme; the legacy field name establishes neither.
• Resource rosters remain separate from carriers and provenance records.

When older text also claims approval, permission, gate passage, assurance, causality, comparability, representation, publication effect, or decision, use the pattern that defines or tests that additional claim and let A.10 retain only source recovery, provenance, bounded reliance, and contestability.

#Evidence carriers for quantum-like statements

Use A.10 when a quantum-like statement is being relied on. Name the minimal claim, selected source episteme and edition, any material publication occurrence, form, or carrier, time and currentness, rival explanation, bounded use, unsupported attempted use, and RelianceDisposition. Add producing or interpreting dated U.Work, Method, actual bindings, and a Work-to-value predicate only when those facts are independently current. Use C.16 for ordinary measurement, the relevant C.26 pattern for probe or frame effects, F.9 for Bridge loss, C.29 for representation, and B.3 for material assurance.

The quantum-like label has no evidence weight. A descriptive graph may represent the source and use relations only after those relations are established.

#C.29 mathematical-lens use relation

When a mathematical lens is used in the evidence account, use C.29 for the representation correspondence and lens-use admissibility claim. A.10 may cite that C.29 episteme and record its provenance, currentness, bounded reliance, and later use; an A.10 graph edge does not establish the correspondence. Use C.16 for measurement construction and B.3 for assurance.

#A.10:End

#Revalidate Affected Uses When a Relied-on Source Changes

Pattern type. Method pattern.

Status. Stable.

Normativity. Normative unless a passage is marked informative.

One-sentence summary. When a relied-on source claim changes and its receivers are not yet fully known, bound where uses count, search that frame from both source and receiver sides, confirm actual dependence, apply the relevant direct subject-pattern guidance only across the action-changing reach, obtain the independently governed subject result, and keep the coverage gaps visible.

#Problem Frame

Use this pattern when a claim-bearing source has been revised, replaced, refined, superseded, or challenged and the practical question is not merely whether the source is current, but which existing results or actions actually relied on the changed claim.

The primary EntityOfConcern is the bounded source-to-use structure: the changed claim and the exact direct use relations through which receiving results, decisions, specifications, plans, or actions depended on it. The practitioner is not asked to know every receiver in advance. The first move is to state the source comparison and the present decision that bounds where a receiving use would count.

First useful move. Write:

Source episteme S0 is being compared with later or replacement episteme S1 for question Q. The potentially material claim change is ΔC. Uses will be sought only within search frame F; the first known coverage limits are G.

If no action-relevant claim change is established, stop before opening a multi-use search. A new URL, file, layout, revision label, carrier, or publication occurrence is not by itself a material claim change.

What goes wrong if missed. One team replays every analysis because a version changed. Another preserves every result because the represented world did not change. A third follows citations or graph edges and calls every reachable item affected while missing an undeclared receiver that actually used the premise. All three replace actual reliance with a proxy.

What this buys. The practitioner gets an affected-use revalidation account that is local, replayable, and honest about coverage. They preserve inspected unaffected uses for their stated conditions, prepare only depends branches for application of their direct subject-pattern guidance, record unresolved reliance and inaccessible search surfaces, and stop at the last receiving action that can change.

Not this pattern when.

• Use A.10 when one already-known bounded reliance use is the whole question.
• Use C.2.1, E.17, or E.24.PUB when source identity, edition continuity, publication, carrier, form, audience, or availability is the live question and no several-use revalidation is needed.
• Use G.11 when currentness, decay, refresh planning, or refresh reporting is the live result.
• Use E.15 when the changed object is one FPF pattern edition; it retains Delta-Class, predecessor-function continuity, pattern checks, and its own change result.
• Use the direct subject pattern when the source is unchanged and a sensor, market, organization, law-applicability situation, configuration, or other world-side condition changed.
• Do not use A.10.1 to decide truth, evidence sufficiency, causality, choice, assurance, authority, permission, release, planning, or performed Work. Take those questions directly to their governing patterns.

What changes in practice. A source change no longer means “redo everything” or “update the link.” The team first establishes whether claim content changed or names the missing fact, states where receivers could count and how that area was searched, confirms reliance in the receiving content, and revalidates only the smallest action-changing branch.

#Problem

Source-change impact is difficult precisely when the receiving uses are partly unknown. A source register may know the source but not every later premise. A receiving decision may use an equivalent claim without retaining the same citation. A dependency graph may include declared edges that do no current work and omit an informal premise that does.

The cheapest apparent boundaries are therefore unreliable:

1. a file or edition label says too little about changed meaning;
2. a citation, mention, link, carrier, adjacency, or graph path says too little about actual reliance;
3. a repository search says too little about surfaces it could not inspect;
4. transitive reach says too much when no downstream action can change; and
5. a local revalidation summary says too little about the subject result that justified it.

Without a bounded search frame, “no affected use found” can silently mean “we searched one convenient repository.” Without application of direct subject guidance and an independently obtained subject result, “preserved” or “reopened” becomes an ungoverned universal status. The method must make both errors visible without turning every source change into a corpus-wide programme.

#Forces

#Solution

Start from the changed source, establish a claim-sized difference, bound the receiving-use search, cover that frame from complementary directions, and inspect each candidate before following it. For each actual depends branch, apply the direct pattern that governs the receiving result and obtain that result independently. Complete the common account only after that subject result exists.

#Perform the Nine-Step Move

1. Start from the changed source, not a presumed receiver. Name the predecessor and later or replacement source epistemes, the claim set whose change may matter, and the present question that bounds the search. Leave source identity, edition continuity, access, or applicability unresolved when the required fact is missing.
2. Compare claims rather than files. Separate changes in proposition, subject, scope, applicability, assumptions, limits, evidence status, and effective conditions from wording, layout, publication, carrier, and revision-label changes. If no material claim change is established, take the cheap stop.
3. Select a receiving-use search frame. Name the project, product, portfolio, organization, decision or result families, configurations, intervals, repositories, registers, responsible owners, and explicit exclusions within which a use would count for the present question.
4. State reproducible discovery coverage. Name the exact source identifiers, claim addresses and aliases used; the included search surfaces; the source-outward and receiver-oriented routes; and every unsearched, inaccessible, stale, unindexed, or identity-ambiguous surface.
5. Discover and then name candidate receivers. Use search, citations, lineage, traces, indexes, owner knowledge, or tools to find candidates. Inspect the receiving content and recover the exact premise, evidence-use, operation-argument, specification, decision-basis, or other direct relation. Discovery alone establishes no reliance.
6. Classify and bound reach. Give every found candidate depends, mentions only, or unresolved. Follow a depends branch through another exact use relation only while a receiving action can change. Form one dispatchable discovery-and-reach statement for each branch that needs subject judgment.
7. Apply the direct subject pattern's guidance. Use the discovery-and-reach statement to apply that guidance to the changed claim, exact direct use, current conditions, affected reach, coverage limits, and material subject facts. The practitioner or admitted System carrying out that application may find that the proposed dependence must be narrowed or rejected or that stronger evidence is required. Keep the resulting subject result independently governed and pass it directly to its existing consumers.
8. Complete the common account after the subject result exists. Cite that result, then summarize this affected use locally as preserved, narrowed, reopened, superseded, reliance withdrawn, or blocked. The summary neither replaces the subject result nor changes A.10 RelianceDisposition.
9. Stop at reproducible local closure. Finish when the frame is fixed, every included surface has a stated coverage basis or named gap, every found candidate has a discovery disposition, and every depends branch has a subject result or named blocker. Preserve inspected unaffected uses, history, gaps, the next responsible receiver, and the observation that would reopen the account.

This numbered presentation is an A.22.CGUS learning unfolding, not a lifecycle and not a mandatory sequence of U.Work. Discovery, source recovery, subject inquiry, and communication may overlap. Only the information dependencies in the move impose order.

#Compare the Source at Claim Size

Recover each source as a C.2.1 episteme: a claim-bearing informational object, not its file or display. Name the predecessor and later or replacement episteme, their relevant claim addresses, subjects, interpretation bases, effective conditions, and edition relation when that relation is established.

Treat a difference as material here only when it can alter a receiving action or result. Useful comparison dimensions are:

Wording can change without meaning changing; one word can also reverse an obligation. A text diff is a locator, not the semantic verdict.

If the same source episteme is merely republished on a new carrier, update the governed identity, publication, representation, availability, or one-use reliance facts through C.2.1, E.17, E.24.PUB, and A.10 as applicable. Do not open the several-use search unless availability itself changes the bounded reliance question.

#Bound the Search Frame and Make Coverage Reproducible

Set the frame before treating found candidates as the universe. The frame is ordinary claim content in the account under construction, not a new record kind.

Coverage is adequate only relative to that frame. Use complementary routes:

• Source-outward discovery starts from exact source identifiers, claim addresses, aliases, citations, backlinks, provenance, data or model lineage, declared traces, and transformations.
• Receiver-oriented discovery inspects the included receiving families for the same or an equivalent premise, limit, parameter, assumption, evidence use, or decision basis, even when the source identifier is absent.

One justified complete index may cover both directions. Otherwise state both routes and their limits. For every surface, record the query or inspection basis, the source identifiers and aliases used, the date or source value inspected when it matters, and the result or gap. An unsearched, inaccessible, stale, unindexed, or identity-ambiguous surface is a discovery-coverage gap. Outside the covered surface, a use is not found, not established unaffected.

#Confirm Direct Reliance Before Following Reach

Search output supplies candidates. The receiving content supplies the reliance test.

These discovery dispositions answer whether a found candidate belongs in the affected branch. They are not A.10 RelianceDisposition values. A.10 still decides whether one bounded evidence use passes, degrades, abstains, reopens, needs evidence or assurance, or is blocked for current use.

A citation, a present or missing trace, storage, indexing, carrier co-location, succession, ownership, declared dependency, graph reachability, or a shared keyword establishes neither depends nor performed Work. A missing trace may be a discovery or coverage gap; it is not impact and it does not prove no impact. Conversely, an undeclared use can depend when the receiving content actually uses an equivalent premise.

Follow a depends branch only through another exact direct use relation. Stop before a downstream item whose action, condition, result, or required check cannot change. The affected reach is the smallest dependency-closed structure that contains every in-frame action-changing receiver; it is not every transitively reachable node.

For each branch that requires application of direct subject-pattern guidance, write a discovery-and-reach statement containing:

The statement is dispatchable claim content, not a new mandatory carrier or universal record. A table, list, matrix, or optional G.6 path slice may present it; the representation establishes none of its relations.

#Apply Direct Subject Guidance and Keep the Result Independent

The common move ends before subject judgment. A practitioner or admitted System applies the direct subject pattern's concrete rule or test to each depends branch. Re-establish only the current conditions, evidence, authority, cost, and Work that can change the independently governed result.

A practitioner or admitted System may, by applying the direct subject rule or test, narrow or reject the proposed affected reach. Keep the independently obtained result on its existing direct route: the engineering source-change result governed by SYSE.19 goes to SYSE.14; revision feedback governed by FIN.17 goes to FIN.4; and the assumption-impact result governed by STR.2 goes to STR.3 and STR.4.

The completed A.10.1 account is never an input to the subject result it later cites. The composition is acyclic:

changed source → bounded search frame and coverage → discovery-and-reach statement → application of direct subject guidance → independently governed subject result → completed affected-use revalidation account

#Complete the Affected-Use Revalidation Account

Complete the common account only after every resolved depends branch has a subject result. The account may be an ordinary C.2.1 episteme when it must be durable or relied on; no dedicated affected-use record kind is required.

Preserved, narrowed, reopened, superseded, reliance withdrawn, and blocked are local prose summaries, not a universal status vocabulary. They do not replace a subject result, RelianceDisposition, assurance, permission, authority, release, or decision.

Keep earlier source editions and prior results recoverable for their original uses and conditions. A later source does not rewrite what an earlier source meant. Reuse a prior result only when its conclusion and conditions remain current and the changed claim lies outside its actual dependency.

#Stop, Return Gaps, and Reopen Locally

A clean local stop requires:

• one fixed search frame for the present question;
• a reproducible coverage basis or named gap for every included surface;
• a disposition for every found candidate;
• an exact direct-use relation for every depends branch;
• action-changing dependency closure with a stated stop;
• a subject result or named blocker for every depends branch; and
• preserved history, inspected unaffected uses, unresolved items, next receiver, and reopen observation.

When a coverage gap remains, finish independent resolved branches and return a scoped unresolved or blocked account for that surface. Do not describe undiscovered uses there as unaffected. Reopen only when a named source, claim, relation, included surface, subject result, applicability condition, or observation changes enough to affect the current conclusion.

#Archetypal Grounding

Tell. A source change matters through a claim that a receiving use actually relied on. Search helps find possible receivers; the receiver and its direct subject rule decide whether action changes.

#Show: Sensor-Calibration Range in an Actual Engineering Host

A pump-controller project used edition E2 of a sensor-calibration MethodDescription. E2 states that temperature compensation for module TS-2 is valid from -20 °C to 50 °C. E3 narrows ordinary validity to -10 °C through 50 °C and requires a new calibration Method and evidence below that range.

The search frame is the named pump-controller project, TS-2 configurations, current service-release interval, and the model, test, safety, interface-architecture, and decision stores used for that release question. Other hardware configurations are excluded when they do not use TS-2 under the changed condition.

The source-outward route follows exact E2 references and established traces. The receiver-oriented route scans the included stores for the old temperature range and equivalent cold-start premises. Inspection finds:

• the thermal-model parameter bound depends;
• the cold-start test condition depends;
• the safety claim's use of evidence produced under that condition depends, and its action-changing reach continues to the service-release premise; and
• the interface description's bibliography entry mentions only.

The affected reach stops at the last service-release action that can change. A practitioner or admitted System applies SYSE.19 to the discovery-and-reach statement. The independently governed engineering revalidation result records evidence that supports units S006–S008 under the tested conditions and leaves S009–S010 without the needed calibration evidence. That result goes directly to SYSE.14, where the authorized release decision remains. Only afterward does the common account cite that result, preserve the bibliography-only use and unaffected configurations, and summarize the affected release branches.

#Show: Financial Model and Data Refresh

A market-data supplier corrects a yield-curve claim for a named date range. The old claim was used by a valuation model and a cash forecast; a nearby finance memo merely cites the vendor report.

The search frame fixes the corporation and portfolio, jurisdiction, decision date, currency and instrument families, model and dataset inventory, finance-account stores, and the desks and periods explicitly excluded from the current question. Data lineage and source identifiers provide the source-outward route. A receiver-side scan checks model inputs, forecast assumptions, liquidity-account premises, and exposure calculations for the same or an equivalent claim.

The valuation input and forecast assumption are depends. The nearby memo is mentions only. One local workbook cannot be accessed, so that workbook is a discovery-coverage gap; it is not called unaffected. A practitioner or admitted System applies FIN.17 to the resolved discovery-and-reach statements, retaining finance-specific model, data, jurisdiction, accounting, reconciliation, evidence, and authority judgments within that application. The independently governed finance result goes as revision feedback directly to FIN.4. The common account cites that finance result afterward and keeps the inaccessible workbook as an explicit continuation item.

#Show: A Changed Research Estimate Is Only One Kind of Strategic Signal

An industry-research edition corrects an adoption estimate used as a premise for one strategic assumption and option. Nearby scenario prose cites the report without using the estimate.

The search frame fixes the named strategic decision, assumption and option registers, current scenario set, decision horizon, and source store. Source references and a receiver-side assumption scan identify the relied-on assumption branch as depends and the nearby citation as mentions only. An inaccessible business-unit assumption store remains a coverage gap.

A practitioner or admitted System applies STR.2 to the discovery-and-reach statement. That application keeps signal qualification, uncertainty, the affected strategic assumption, option or commitment consequences, horizon, and the assumption-impact result within STR.2's governing scope. The independently governed assumption-impact result goes directly to STR.3 and STR.4. A market or competitor change with no changed source claim goes straight to STR.2; it is not forced through A.10.1.

#Reduced Boundary Cases

#Bias-Annotation

This pattern counteracts version bias, visibility bias, graph-completeness bias, and authority transfer. A newer or official source deserves inspection, but recency and status do not establish materiality for a named use. A visible link or graph path is easier to count than an undeclared premise, and a polished impact report can look like a subject verdict.

The repair is deliberately asymmetric: tools may broaden candidate discovery, while inspection of direct receiving content and application of the direct subject rule or test narrow what can be concluded. The pattern therefore favors recoverable local closure over confident global claims. Sensitive repositories may use scoped, redacted, hashed, or responsible-party-attested searches, but their access limits remain visible.

#Conformance Checklist

#Common Anti-Patterns and How to Avoid Them

#Consequences

Benefits. Source changes receive effort proportional to their actual use. Teams can preserve inspected unaffected results, expose undeclared dependencies, continue clean branches despite a local gap, and apply the correct governing pattern to each affected question while preserving its evidence and authority boundaries. The account remains usable without a mandatory graph, matrix, workflow, or new ontology.

Costs and limits. Claim-sized comparison and receiver-oriented inspection require judgment. Coverage can be expensive when repositories are fragmented or access is restricted. The method makes those limits visible; it cannot convert incomplete access into assurance. A genuinely broad claim with many actual consumers can still produce broad revalidation.

Failure containment. A missing source fact, unresolved direct relation, inaccessible surface, or subject blocker narrows or blocks only the affected frame or branch. It neither invalidates unrelated uses nor supports a global unaffected-use claim.

#Rationale

The pattern begins under A.10 because a source change matters through reliance, not through source succession alone. It is separate from A.10 because one known source-to-use account and the discovery of several partly unknown receivers have different first actions, coverage burdens, and stop rules.

The search frame solves the unknown-receiver problem without claiming a universal corpus. Complementary discovery solves a second asymmetry: source-side traces miss undeclared or equivalent premises, while receiver-side searches can miss transformed or aliased source content. The direct-use test then prevents either search route from becoming semantic authority.

The subject-application/result sequence is deliberately acyclic. The common method can identify where subject judgment is needed, but applying it does not establish engineering release, finance reconciliation, strategic consequence, assurance, permission, or other domain meaning. Completing the account afterward preserves one practical overview without replacing the independently governed results that justify it.

No new kind or primitive relation is needed. Existing epistemes, direct relations, subject results, Work, plans, publications, and representations can carry every required claim. The method contributes a reusable action boundary, not an impact ontology.

#SoTA-Echoing

The practical SoTA contribution is the combination of claim-sized comparison, bounded bidirectional discovery, actual-use classification, dependency-closed reach, reuse of unaffected results, and an acyclic subject-application/result sequence. No one graph, repository, or status vocabulary substitutes for that combination.

#Relations

Builds on:

• C.2.1 for source-episteme identity, claim content, subject, interpretation basis, edition continuity, and publication/carrier separation.
• A.10 for each exact source-to-use account and its independent RelianceDisposition.
• A.11 for using existing kinds, relations, results, records, forms, and representations instead of minting an impact ontology.

Coordinates with:

• G.6 when an addressable evidence or provenance path slice is useful; graph representation remains optional and establishes no reliance.
• G.11 when currentness, decay, or the completed result justifies a refresh plan or report; G.11's result shape remains unchanged.
• E.15 as the specialization for changes to one FPF pattern edition, retaining Delta-Class, predecessor-function continuity, proportionate pattern checks, and its candidate-plus-change-account result.
• B.3 and every direct evidence, truth, causal, choice, authority, permission, gate, release, planning, and Work pattern governing the corresponding results.

Supplies: A practitioner using A.10.1 obtains a bounded discovery-and-reach statement for application of SYSE.19, FIN.17, STR.2, PSD.14, or another direct subject pattern when its actual receiving content relied on the changed claim. The independently governed subject result continues directly to its existing consumers; the completed A.10.1 account cites it afterward.

Constrains: changed-source affected-use discovery and local closure only. A.10.1 creates no new source, relation, graph fact, subject verdict, assurance, authority, permission, release, Work occurrence, plan, or universal status.

#A.10.1:End

#Ontological Parsimony

Type: Kernel parsimony and admission discipline pattern Status: Stable Normativity: Normative unless a section is explicitly informative

#Use This When

Use this pattern when FPF work proposes a new U-kind, core relation, dependent durable value, or public structural name and the current question is whether existing ontology can express the claim without creating a new kind.

Typical moments:

• a new U-kind seems useful after E.24.UK;
• a proposed root kind may actually be a dependent value, slot, relation, record, publication form, lens, local frame, or C.3 U.Kind;
• two candidates overlap strongly;
• a name is convenient but the ontology may already be expressible through existing patterns.

Primary EntityOfConcern. The EntityOfConcern is the parsimony claim for one candidate ontology addition.

First useful move. Recover the candidate with E.24.UK or the subject pattern, then ask what current FPF values, slots, relations, and patterns can already express.

What goes wrong if missed. FPF grows duplicate kinds for slot positions, local names, publication forms, mathematical lenses, and records. Later patterns then argue over words instead of recovering the EntityOfConcern, relation, slot, and admissible claim.

What this buys. A small ontology can still express rich project situations: the pattern either admits a new durable value with a boundary, or shows exactly which existing kind, slot, relation, record, publication form, lens, or direct pattern already carries the claim.

Not this pattern when. Not this pattern when the current question is only a local display name, publication title, naming taste, or ordinary glossary cleanup. Use the relevant Part F naming pattern unless the name is being asked to carry durable ontology.

#Problem Frame

FPF needs enough primitives to be useful, but every new primitive creates learning cost, bridge cost, and future repair cost. Ontological parsimony is not anti-growth. It is the rule that FPF adds a new kind only when composition, reuse, dependent-value settlement, and subject patterns cannot express the action-facing claim without material loss.

When source or draft wording proposes a candidate durable value in U.* form, treat that as an admission claim. A.11 is therefore applied after E.24.UK recovers the governed object and before naming patterns choose a public label. For a relation-kind candidate, the ExistingExpressionAttempt first uses A.6.P and, only when the exact participants are known but no current direct relation closes the named receiving claim, A.6.RCD. An existing-relation, local-compound-claim, or predicate-definition result closes the primitive candidate; a separately justified derived relation kind proceeds only as derived, and only an irreducible primitive-relation-kind result can continue here as primitive.

#Problem

A useful project word, slot-position label, publication form, diagram element, mathematical lens, or repeated source term can start acting like a durable FPF kind before the governed object and subject pattern are recovered. The problem is to decide whether the candidate preserves an action-facing distinction that composition cannot carry, or whether it should remain a local name, slot value, relation, record, publication form, or lens-use claim.

#Forces

#Solution

Use four gates before admitting the new ontology addition:

Use this compact record:

ParsimonyAdmissionRecord:
  Candidate:
  RecoveredGovernedObject:
  E24FamilySettlementDecisionRef: exact shared decision governed by E.24:4.0a; do not fill another E.24.UK decision form.
  ExistingExpressionAttempt:
  MaterialLossIfComposed:
  OverlapWithExistingValues:
  ActionFacingContribution:
  BoundaryTest:
  Disposition:

Possible dispositions:

• retain as root U-kind;
• retain as dependent durable value under a root settlement;
• apply C.3 typed reasoning;
• express as slot, relation, record, publication form, lens, local frame, or direct governed value;
• keep as source wording or local name.

#Archetypal Grounding - Maintenance

A retained addition also needs a reopen condition. Reopen or lower the admission when usage collapses, overlap with an existing value is discovered, composition becomes adequate, the boundary becomes fuzzy, or the name starts hiding a slot, relation, record, publication form, lens, or local frame. This is maintenance discipline, not a fixed calendar ritual.

#Bias-Annotation

A.11 corrects kind-inflation bias. A useful word, field name, record label, or diagram element can start behaving like a universal kind because it appears often, feels important, or has prestige in a source tradition. The repair is ontological: recover the governed object and try expression through existing U-kinds, slots, relations, dependent values, records, publication forms, lenses, and subject patterns before admitting a new durable value.

It also corrects false-parsimony bias. A compact ontology is not achieved by refusing every new value. If composition hides a reviewable distinction or blocks an action-facing claim, parsimony admits the new value and states its boundary, overlap, and reopen condition.

#Conformance Checklist

#Common Anti-Patterns and How to Avoid Them

• Slot label becomes kind. A system-role designation, transformation-participant label, source-maintenance position, carrier position, or boundary slot is renamed as if the label created a new universal kind; recover the admitted System, exact local system-role kind or direct relation, any separately obtaining assignment, and Work only when each is current.
• Publication form becomes ontology. A card, record, view, dashboard, figure, or report title is treated as the governed object instead of the episteme, relation, or carrier it publishes.
• Mathematical lens becomes object. A graph, tuple, algebra, metric, coordinate, or threshold is admitted as an ontology object without naming the EntityOfConcern and lens-use claim.
• Local project name becomes kernel vocabulary. A useful project label is promoted to durable FPF vocabulary before composition and direct-pattern expression are tried.
• Overlap is ignored. A candidate is admitted even though an existing pattern already carries the same claim with clearer boundaries.
• Parsimony as refusal. A new value is rejected because "fewer kinds is better" even though existing composition loses a distinction users need to claim, compare, repair, stop, or rely on.

#Consequences

#Rationale

Ontological parsimony preserves FPF's ability to handle many domains without turning every local distinction into a root object. The pattern follows the same discipline used by E.24.UK: recover the governed object first, then decide whether a new durable value is needed. Slots, relations, dependent values, records, publication forms, and mathematical lenses are expressive resources; they are not failures to mint a kind.

The practical criterion is not abstract minimalism. A candidate earns admission only when users gain a claim, comparison, repair, stop condition, reliance condition, or boundary they cannot recover by composition without material loss. That keeps parsimony tied to FPF's work-facing purpose rather than to a taste for small vocabularies.

#SoTA-Echoing

Current ontology-engineering practice favors modularity, reuse, explicit competency questions, and controlled admission of new terms over unchecked class growth. A.11 adapts that practice to FPF: the admission question is not merely "can a class be defined?" but whether the candidate changes admissible claims, boundaries, or work-facing use inside the FPF pattern system.

Constructional-ontology and BORO-like source lines add a second discipline: identity, construction, dependency, and part-whole distinctions must be recovered before a convenient term becomes a kind. FPF keeps that source discipline without importing a classical top-level taxonomy as-is; U-kinds remain tied to accepted ontics, slot discipline, and action-facing pattern use.

#Relations

• Builds on: E.24.UK, A.6.P, A.6.RCD, A.8, C.3, F.8, F.18, and direct subject patterns.
• Coordinates with: E.24.CD for candidate detection and E.24.PUB when a publication form or structural name created the admission claim.
• Does not replace: universal-core testing in A.8, typed claim quantification in C.3, or naming discipline in Part F.

#A.11:End

#Decision-Relevant Least Action and Operational Parsimony

Type: Part A pragmatic principle pattern Class: Prag Status: Stable Normativity: Normative unless marked informative

Plain name. Keep only work that changes a substantive choice or result, or protects a condition on which the use relies.

Primary reader. A practitioner or designer deciding whether one proposed action, step, check, record, wait, cue, tool use, or other apparatus should be mandatory.

#Problem frame

Use this when. Use this pattern when someone proposes making an action or apparatus mandatory and a plausible question remains: does this requirement change the subject work, or does it only make the route look controlled?

The primary EntityOfConcern is one proposed mandatory requirement under one declared use and one substantive horizon. Action, apparatus, requirement, and horizon are ordinary working words here. This pattern introduces no generic U.Apparatus, U.Move, action kind, horizon kind, or result record.

First useful result. Return one of two short answers:

• retain the requirement for this use and horizon because it changes a named substantive branch, realizes an already selected result, or preserves a named assurance or recovery condition on which the use relies; or
• remove the requirement or leave it optional because none of those conditions changes when it is removed.

Ordinary use needs no score or separate record. Name the receiving decision, result, reliance, or recovery condition in the same sentence as the disposition.

Three recognition cases.

• A team has added a second status update before a repair decision. Every possible status leaves the same repair action, and no later user relies on the duplicate update.
• A laboratory considers a bounded probe that leaves today's setup unchanged but can determine which of two methods will be used next week.
• A release route contains both a deterministic build step that creates the selected publication and an assurance check whose evidence is consumed by the release decision.

These are one recurring problem across unlike situations: mandatory effort can be ceremonial, immediately productive, decision-relevant only later, or necessary because another use relies on the assurance or recovery condition it preserves.

What goes wrong if missed. Requirements accumulate because each sounds prudent in isolation, while their possible results change no substantive choice and produce no selected result. The opposite error removes exploration, deterministic realization, safety evidence, recovery support, or a small discriminating cue merely because it does not change the next administrative state.

What this buys. The practitioner can remove ceremony without treating the fewest steps as the goal. Useful exploration, realization work, assurance, option preservation, and recovery remain when their receiving use is named.

Not this pattern when.

• When a law, regulation, duty, permission, prohibition, safety floor, evidence rule, or gate condition is in question, use the pattern or authority that establishes that obligation. This pattern neither creates nor cancels it.
• When several already qualifying alternatives need comparison, use their direct choice, apparatus, architecture, or Method Engineering pattern.
• When the question is whether a new durable ontology value should exist, use A.11.
• When the question is how to use an already selected pattern, use E.11.PUA or E.11.PUR.
• When ongoing Work needs one next action chosen from current facts, use A.15.7.
• When an available direct-kind apparatus is already being configured for a declared use, use C.19.2 for that application question.

#Problem

Methods, workflows, reviews, and support arrangements can accumulate reads, meetings, checks, fields, records, waits, handoffs, prompts, and tool calls. Each addition can be defended by a possible future benefit. If hypothetical usefulness is enough, every requirement survives. Attention and elapsed time then move from the subject result to the route's own states and receipts.

Simple minimization fails in the other direction. A deterministic assembly step may have no rival outcome yet still create the selected result. Information may change a later policy rather than the immediate action. A safety check may confirm the expected state while supplying evidence on which release reliance depends. A recovery cue may prevent continuation from the wrong place. Counting branches, steps, documents, or minutes does not distinguish those cases.

The problem is therefore not how to minimize action in general. It is how to admit one proposed mandatory requirement only when a materially plausible difference reaches a named substantive use, without weakening the direct authority that governs the action.

#Forces

#Solution

Apply one bounded admission question before making the proposed action or apparatus mandatory.

Admission rule. An author or method designer MUST NOT make a proposed action or apparatus mandatory unless at least one materially plausible result can change a named substantive decision or branch within the declared horizon, the action realizes an already selected transformation or required subject result, or removing it changes a named assurance or recoverability condition on which the declared use relies.

Passing one branch means only that the requirement is not ceremonial for this use and horizon. It does not establish authorization, sufficiency, completion, optimality, minimum cost, safety, legal permission, or precedence.

#Name the use and nearest substantive horizon

1. Name the proposed requirement and the declared use for which mandatory status is being considered.
2. End the horizon at the nearest named substantive decision, receiving use, selected transformation result, assurance use, or recovery use that can justify the requirement.
3. Name the possible result or removal consequence that reaches that horizon. Do not use the requirement's own status, completion flag, receipt, or other administrative transition as its receiver.

The nearest substantive horizon is not necessarily the next event. It may include a later decision when the dependency from the present result to that decision is stated. It does not extend through an unnamed audit, unspecified future reuse, a merely possible receiver, or an indefinite claim that the action may be useful someday.

#Compare keeping and removing through three branches

Compare the concrete situation with and without the requirement. If one branch passes, retain the requirement at no more formality than its direct owner and named reliance need justify. If several forms pass, return their comparison to the direct choice, apparatus, architecture, or Method Engineering owner rather than inventing one scalar minimum.

If no branch passes, remove the requirement or leave it as an optional convenience. Do not preserve mandatory status merely because the action is cheap, familiar, automated, prestigious, measurable, or already present.

#Judge material plausibility through the subject claim

Materially plausible means more than logical possibility and less than certainty. The applicable subject, evidence, causal, risk, decision, or assurance pattern supplies the basis appropriate to the consequence. A low-probability result can remain material when its consequence changes exposure or the admissible policy. A large information volume is not material unless some result can change a named receiving use.

When the basis needed to distinguish branches is absent, return the missing basis or run a bounded experiment whose possible results can genuinely change the named decision. Do not convert uncertainty about usefulness into a permanent mandatory requirement.

#Return authority and claims to their direct owners

Apply this screen inside the space left by current authority. Law and regulation, E.5 Guard-Rails, B.3 assurance floors, and a direct evidence, gate, duty, or safety pattern remain controlling. If their basis or applicability is disputed, return to that authority; do not use operational parsimony as an appeal court.

A passing result also leaves downstream claims separate:

• A.3.1 and A.3.2 establish Method and MethodDescription identity;
• A.15.1 establishes dated Work, while A.15.7 selects a next action during ongoing Work;
• C.11, C.19.2, A.19, and Method Engineering compare qualifying alternatives under their own conditions;
• A.10, B.3, and the applicable gate or duty pattern establish evidence, assurance, acceptance, and authority claims; and
• E.13 repairs proxy displacement, while E.23 governs operations inside a repeated evaluated improvement loop.

The admission result supplies none of those conclusions by itself.

#Keep the result light and reopenable

For ordinary use, say:

Keep <requirement> for <declared use> until <nearest substantive horizon> because <named branch and receiving difference>.

or:

Remove or demote <requirement> for <declared use> because keeping and removing it produce the same substantive decision and result and change no relied-on assurance or recovery condition.

Create a durable claim-bearing episteme only when a named later use must cite, compare, audit, or rely on the disposition. Use an existing record kind appropriate to that use. Do not mint an OperationalParsimonyRecord or require a checklist merely to show that this pattern was consulted.

Reopen the disposition when the horizon, plausible results, selected transformation, direct duty, assurance floor, recovery reliance, or burden-bearing alternative changes.

#Keep framework layers distinct

FPF owns this cross-domain admission principle. A Method Engineering DPF may use it when designing requirements, architecture, support, trials, or practical-worth comparisons for a named Method situation; that DPF still owns those Method-specific decisions. A local practice framework may bind the principle to its own execution and assurance mechanisms; those local mechanisms neither become FPF law nor prove that the general admission condition holds.

#Archetypal Grounding

#Duplicate status update and deterministic publication build

A publication repair route asks for a second status update immediately before the repair decision. The update has the same possible values as the first one. None changes repair, stop, or publish, no receiver cites it, and removing it changes no assurance or recovery condition. The second update passes no branch, so the route removes it or leaves it as an optional convenience.

The same route runs a deterministic build after the sources and publication form have been selected. The build has no decision-changing outcome by design, but it assembles the selected sources into the required publication. It passes selected realization and remains. Its admission does not prove source acceptance, publication correctness, release, or availability; those claims retain their direct owners.

#Exploration whose value appears in a later decision

A maintenance team must choose next week between Method A and Method B for a recurring seal failure. A bounded probe performed today can return one of three observations: evidence favoring A, evidence favoring B, or an unresolved result that triggers a hold. Today's immediate action is unchanged, but every possible probe result has a named effect on the later Method-selection decision.

The probe passes the decision-changing-result branch. Its horizon ends at that named selection and its stated window, not at the probe's completion flag. If the team later shows that every possible observation leads to Method A, the probe no longer passes for that use and is removed, redesigned, or made optional.

#Assurance evidence with an unchanged operating decision

A pressure-system release check is expected to confirm the current operating decision. The release authority nevertheless relies on its evidence, and omission changes the accepted exposure for release. The check passes assurance preservation even when its most likely result leaves the operating branch unchanged.

B.3, the applicable evidence pattern, and the release authority set the assurance floor and disposition. A.11.OP only prevents the check from being dismissed as ceremony because it confirmed the expected state. A precautionary label without a named reliance, exposure change, or direct owner would not receive the same treatment.

#Recovery cue and discriminating language

After an interrupted multi-part analysis, a small cursor identifies the last closed item and the next item. Removing it can cause the practitioner to repeat completed work or resume from the wrong branch. The cue passes recovery preservation while that continuation use relies on it. If the task is short and the next item is already unambiguous, the same cursor becomes optional.

In another case, a sentence must distinguish a reusable Method from dated Work that enacted it. The distinction changes whether the practitioner repairs a description claim or a performance claim. The language passes the decision-changing-result branch for that use. The example creates no blanket exception for terminology: a distinction that changes no interpretation or action is informative at most.

#Speculative compliance without a receiver

A team proposes generating a compliance packet for possible future reuse. No law, duty, regulator, customer, gate, decision, assurance use, or recovery dependency is named. The packet therefore passes no branch and is not mandatory.

If an applicable duty or relying receiver is later established, reopen the disposition under that direct authority. The earlier speculative possibility was not evidence that the duty already existed.

#Bias-Annotation

Scope: Universal for the cross-domain admission question governed by this pattern.

#Conformance Checklist

#Common Anti-Patterns and How to Avoid Them

#Consequences

The pattern changes practice before a requirement is installed. A designer names the receiving horizon and checks what keeping or removing the requirement changes. Duplicate status work becomes removable without making “less paperwork” a universal argument. Deterministic transformations remain because they produce the selected result. Exploration, assurance, recovery, and small cues remain when their delayed or relied-on consequence is explicit.

#Rationale

Operational parsimony is about relevance, not abstract minimization. The fewest-step method can be wrong when one additional action realizes the chosen result, changes a later policy, or preserves a relied-on condition. The longest method can also be wrong when its extra actions have no substantive receiver. Comparing keeping and removing one proposed requirement makes that difference visible without inventing a global cost function.

The three branches cover distinct reasons for mandatory status. Decision-changing result preserves exploration and discrimination. Selected realization preserves deterministic work. Assurance or recoverability preservation protects evidence, exposure, restart, rollback, and option value when another use relies on them. None of those reasons supplies the stronger claim governed by its direct owner.

The horizon must be substantive and bounded. A next-event horizon hides delayed information value; an indefinite horizon lets hypothetical future usefulness justify everything. The nearest named receiver is the smallest horizon that can carry the reason and the smallest reopen boundary when the use changes.

No new ontology or record is needed. The rule coordinates existing decisions, transformations, results, evidence, assurance, and recovery uses. Keeping these objects under their direct patterns preserves FPF layering while giving practitioners one discoverable admission question.

#SoTA-Echoing

#Relations

• Classified by: E.3 as one Prag principle. It primarily advances P-1 Cognitive Elegance, P-7 Pragmatic Utility, P-10 Open-Ended Evolution, and P-11 State-of-the-Art Alignment while respecting the other Pillars. It adds no custom precedence edge.
• Coordinates with, but does not specialize: A.11, which governs admission of ontology additions. Namespace adjacency makes the two parsimony questions discoverable without combining their EntitiesOfConcern.
• Coordinates with: E.11.PUA and E.11.PUR, which govern use, recommendation, coordination, and reuse after a pattern has been selected. A.11.OP asks whether an extra mandatory requirement belongs in the first place.
• Coordinates with: C.19.2, which governs bounded application and configuration of available direct-kind apparatus. Passing A.11.OP neither meets its application threshold nor chooses among configurations.
• Coordinates with: E.13 for proxy-to-value repair and E.23 for operations inside repeated evaluated improvement. Neither is the general owner of initial action admission.
• Coordinates with: A.3.1 and A.3.2 for Method and MethodDescription identity, and with A.15.7 for next-action choice during ongoing Work. A.11.OP governs design-time admission of the requirement rather than Method identity or live steering.
• Constrained by: law and regulation, E.5 Guard-Rails, B.3 assurance floors, and the direct evidence, gate, duty, safety, choice, Work, transformation, publication, and authority patterns applicable to the use.
• Consumed by: Method Engineering and other DPFs when they decide whether domain-specific requirements or support apparatus deserve mandatory status. Those frameworks retain their domain questions, architecture, evidence, and practical-worth decisions.
• May be specialized by: local practice frameworks for concrete execution and assurance. Their local arrangements remain local rather than FPF authority.

#A.11.OP:End

#Acting-Side Externalization and Reflexive Split

Type: Part A architectural ontology pattern Status: Stable Normativity: Normative unless a section is explicitly informative

#Use This When

Use this pattern when a source says that something changes, repairs, configures, updates, verifies, teaches, controls, or improves itself, or when the acting side of a change is hidden behind a passive or self-action sentence.

Typical moments:

• "the robot calibrates itself";
• "the model updates itself";
• "the document refreshes its own cross-references";
• "the organization corrected itself";
• "the system verifies that its own change succeeded";
• "the lathe makes the workpiece, therefore the workpiece is part of the lathe during manufacturing".

First useful move. Separate the exact continuing subject named as changed from the exact entity proposed for the acting side. Identify the changed subject by the identity rule that defines that referent. Before calling the acting-side entity a U.System, show that it satisfies the complete A.1 criterion; otherwise retain the exact U.Entity and its recognized | rejected | unknown disposition or exact blocker and leave the acting-system position empty. After recognition, name that U.System and recover its exact acting-side participation relation. Add an obtaining occurrence of one directly declared U.SystemRoleAssignment species under A.2.1 only when the work-facing claim uses it; use A.2.7 separately only for a relation among exact local system-role kinds. If an actual bounded change is current, use A.3.4's change test for that same continuing subject; use A.15 and A.15.1 for Method and Work, F.6 for Work attribution, A.10 for evidence, and A.1, A.14, or C.13 for holon and part-whole claims.

What goes wrong if missed. A system becomes its own cause, a document acts, a controller and controlled part collapse into one object, evidence becomes self-certifying, and a system that changes another holon is mistaken for the larger whole containing it without an obtaining part-whole relation.

What this buys. Self-action wording becomes a reviewable relation among one exact continuing changed subject, the exact entity proposed for the acting side, its same-entity U.System reading only after A.1 recognition, and any separately governed participation, role, method, Work, boundary-crossing, or evidence claims that are current. Reflexive use remains the narrower holon case with two exact parts or subsystems.

Not this pattern when.

• If the current question is whether a bounded change occurred, use A.3.4.
• If the current question is whether work was performed or succeeded, use A.15 and A.15.1.
• If the current question is an assignment occurrence, use A.2.1; if it is a relation among exact local system-role kinds, use A.2.7. For another participation relation, use the pattern that defines that relation.
• If the current question is evidence independence or source use, use A.10 and the evidence-use or source-use patterns.
• If the current question is part-whole admission, use A.1, A.14, and C.13.

#Problem Frame

A.12 keeps a causality-facing modeling discipline without creating a second transformation ontology.

The pattern does not say that every change is already established, that work succeeded, that the acting-side entity has already been recognized as a system, that it belongs to a special U.Transformer kind, or that boundary wording creates a durable boundary object. It says only this: when a claim depends on a change, recover the exact changed participant and the exact entity proposed for the acting side as distinct participants in that claim. When ordinary language says "self-", split the larger holon into distinct acting and changed positions before using transformation, method, work, evidence, or part-whole patterns.

#Problem

Without A.12:

1. Self-action hides the acting side. "The system changed itself" does not say which exact entity occupies the acting side, whether that entity satisfies the complete A.1 U.System criterion, which exact continuing subject is claimed to change, or which direct relation defines the participation claim.
2. Transformation and work collapse. A bounded transformation, a method, a work occurrence, and evidence of success are treated as the same claim.
3. Epistemes become agents. A document, model, source record, report, or theory is said to update, decide, authorize, or verify itself.
4. Reflexive systems become single blocks. A regulator and regulated part are hidden inside one block, so failure analysis and architecture work lose the internal relation that mattered.
5. Transformation becomes containment. A system changing another holon is treated as that holon's containing whole.
6. Evidence becomes self-certifying. The acting system's own output is treated as sufficient evidence for the success or safety of its work.

#Forces

#Solution

Use A.12 as a thin acting-side pattern.

#Acting-Side Externalization

For a change-bearing claim, recover this relation frame before relying on self-action wording:

ActingSideExternalization@Context:
  changedSubjectRef: one exact continuing referent identified by the identity rule that defines that referent
  actingEntityRef: exact U.Entity proposed for the acting side
  actingSystemRef?: U.System, fill only after actingEntityRef satisfies the complete A.1 U.System criterion
  a1RecognitionDispositionOrBlockerRef?: required while actingSystemRef is unfilled
  actingSystemRoleAssignmentRef?: U.RelationRef constrained to U.SystemRoleAssignment, only when one exact obtaining work-facing assignment is current
  actingSideParticipationRef?: one exact obtaining relation occurrence satisfying the predicate and participant meanings that define the participation, causal, or interaction claim
  transformationRef?: U.Transformation, fill only when A.3.4 identifies a bounded change of changedSubjectRef
  methodRef?
  methodDescriptionRef?
  workPlanRef?
  workOccurrenceRef?
  holonBoundaryCrossingRelationRef?: one exact obtaining relation occurrence satisfying the predicate, applicability, and identity rules that define the crossing relation
  evidenceRelationRefs?
  strongerOwnerRefs:

The exact entity in actingEntityRef and the exact referent in changedSubjectRef are distinct participants in the current change-bearing claim. changedSubjectRef is a question-local position, not a U-kind or union ValueKind: its value keeps its independently admitted kind and the identity rule that defines that referent. A presentation carrier does not become a U.Holon by filling the position, and a transformation reference is filled only when the practitioner applies A.3.4's change test to that same continuing referent. Before A.1 recognition, the exact disposition or blocker remains explicit and actingSystemRef stays unfilled. After recognition, actingSystemRef identifies that same acting-side entity under U.System; it does not introduce another actor. The participants may be parts of a larger holon and may be tightly coupled, but the acting position is not the changed position for that claim.

ActingSideExternalization@Context is a relation frame, not a U-kind, acting-system kind, record that acts, or evidence that change occurred. For each neighboring claim it names the exact subject and actual participants and may cite the pattern or rule that defines, constrains, or tests its direct predicate. Neither A.12 frame has a generic context, scope, or qualifier position. First ask what the qualifier changes. If it changes claim content, EntityOfConcern, or the effective reference scheme, C.2.1 identifies another episteme. If it selects whether one exact U.ContextSlice belongs to the set-valued applicability boundary of a claim, A.2.6 defines the exact U.ClaimScope and membership evaluation. Select a BoundedModelUseStructure under A.1.1 only when the named decision use depends on the joint organization of one model edition's applicability, actual use in assigned Work, fixed-content expression coherence, exact applied constraints, and a complete selection-use frame. Otherwise state the exact condition, value, or relation as a claim and apply or cite the rule that defines or tests it. Recover an exact defining or constraining ClaimGraph only when its identity materially changes interpretation, comparison, migration, conflict, publication, or reuse. Do not copy a claim phrase or nearby participants into an A.12 field, and do not invent one umbrella qualifier object.

Use:

• [A.3.4](/generated/patterns/A.3.4) when transformationRef becomes current;
• [A.15](/generated/patterns/A.15) and [A.15.1](/generated/patterns/A.15.1) when method, work plan, work occurrence, or work success becomes current;
• [A.2.1](/generated/patterns/A.2.1) when an exact assignment occurrence becomes current, and [A.2.7](/generated/patterns/A.2.7) only when a relation among exact local system-role kinds becomes current;
• [A.10](/generated/patterns/A.10) when evidence or source independence becomes current;
• [A.1](/generated/patterns/A.1), [A.14](/generated/patterns/A.14), and [C.13](/generated/patterns/C.13) when holon identity, part-whole, or constructive grounding becomes current.

#Reflexive Split

For "self-" claims, do not accept the self-action wording directly. Recover one larger holon and two exact entity parts or subsystems inside it:

ReflexiveSplit@Context:
  containingHolonRef: exact U.Holon
  actingPartOrSubsystemRef: exact U.Entity
  changedPartOrSubsystemRef: exact U.Entity
  holonDelimitationRelationRefs?: exact obtaining parthood relations to containingHolonRef
  holonBoundaryCrossingRelationRef?: one exact obtaining relation satisfying the predicate, applicability, and identity rules that define the crossing relation
  actingSystemRoleAssignmentRef?: U.RelationRef constrained to U.SystemRoleAssignment, only when one exact obtaining work-facing assignment is current
  transformationRef?
  methodRef?
  workOccurrenceRef?
  evidenceRelationRefs?

ReflexiveSplit@Context carries no system-recognition position. Its two part-or-subsystem fields identify exact entities, not phases, assignments, relation occurrences, or generic structures. Each filled entity position needs an independently obtaining parthood or subsystem relation to containingHolonRef under A.14 and the direct part-relation specialization.

When the acting-position entity must also be evaluated as a system, use a companion ActingSideExternalization@Context: its actingEntityRef identifies that exact U.Entity; its disposition or blocker remains explicit before recognition; and its optional actingSystemRef may identify the same entity only after A.1 recognition. Do not insert actingSystemRef or an A.1 disposition into ReflexiveSplit@Context.

A temporal phase, system-role assignment, parthood occurrence, software-module description, or selected structure remains a separate object under the identity and relation rules that define it. A software component fills a part-or-subsystem field only when it is itself the exact entity and its direct part relation obtains. If a source supplies only unlike positions such as phases or assignments, state those direct relations and do not force them into this frame.

The minimal rule is:

actingPartOrSubsystemRef != changedPartOrSubsystemRef

for the current change-bearing claim.

#Episteme And Publication Cases

An episteme does not act by itself. If a source says "the document updates itself", first recover the exact acting entity and decide which one of these different changed-object readings is current:

• Carrier-change reading. One exact publication file, representation carrier, or source-record carrier continues through a separately grounded change under its direct carrier identity rule. It may fill changedSubjectRef as that exact carrier, not as a U.Holon merely by carrier form; use A.3.4 only when the bounded change of that same referent is independently admitted.
• Episteme-edition reading. Changed claim content identifies another episteme, with the predecessor, successor, and exact edition relation governed separately. Do not call it transformation of one unchanged episteme.
• Relation-occurrence reading. One exact episteme-related direct relation—for example constitution, empirical grounding, edition, reference, or publication use—obtains when its actual participants satisfy its direct predicate. Its direct identity and change rules determine whether that occurrence continues, ceases, or is replaced. Use C.2.1 for episteme identity and edition distinctions and E.17 or E.24.PUB for publication use. The relation occurrence does not fill changedSubjectRef; if an actual change is also claimed, identify its continuing subject and A.3.4 facts separately.

Choose one reading before filling a singular field; never use a carrier, episteme, and relation occurrence as interchangeable values. Name the acting entity under U.System only after A.1 recognition, and fill a work-facing assignment only when one exact U.SystemRoleAssignment obtains. Use C.2.1, E.17, E.17.2, and the patterns for source use, publication use, carriers, editions, and evidence when those objects or relations are current. A.12 only prevents the sentence from assigning agency to the episteme.

#No Containing-Whole Inference From Interaction

A system changing another holon does not thereby become its part or the larger whole containing it. A manufacturing, teaching, measurement, repair, control, telemetry, or source-use case may contain separately governed boundary-crossing, transformation, work, evidence, or publication-use claims; none is a part-whole claim merely by wording, and A.12 makes none of them obtain.

Use A.14 or the rule defining the exact part-whole predicate only when parthood is independently admitted.

#No Self-Evidence Shortcut

A.12 separates the acting side; it does not make the acting side's own output sufficient evidence for success, safety, adequacy, or authorization.

When evidence matters, use A.10's evidence and source-use relations; use B.3 when an assurance conclusion is also claimed. The evidence relation may use an observer system, measurement setup, independent source, audit record, or accepted stronger relation. A.12 only blocks the overread that acting and evidence are the same by default.

#Archetypal Grounding (Worked Cases)

#Bias-Annotation

#Document Cross-Reference Update

Source wording: "the document updates its cross-references."

This case chooses the carrier-change reading rather than combining it with an episteme-edition or relation-occurrence reading. It invokes no reusable FPF carrier-identity pattern. Its bounded case-local rule treats PublicationFile-17 as the same carrier only if the file object opened for the build still exists when the build closes, every write targets that same open object, and the build neither deletes and recreates the file, atomically replaces it, nor substitutes another carrier. Use E.24.PUB to state what publication form that carrier bears; it does not supply this carrier identity. If a continuity fact fails, identify a replacement carrier and do not assert a transformation of one continuing file; if carrier identity is unresolved, stop. A changed C.2.1 episteme discriminator selects the separate episteme-edition reading, not carrier continuity.

ActingSideExternalization@DocumentBuild:
  changedSubjectRef: PublicationFile-17, the exact continuing U.PresentationCarrier reidentified by the bounded case-local continuity rule stated above
  actingEntityRef: BuildRunner-4
  actingSystemRef: BuildRunner-4, the same entity after it satisfies the complete A.1 U.System criterion
  actingSystemA13CoreRef: A.13 core for BuildRunner-4 as precise performer in this action, including CrossReferenceUpdateAssignment-27 as the same obtaining assignment
  methodRef: CrossReferenceUpdateMethod-3, admitted under A.3.1
  methodDescriptionRef: BuildScriptEpisteme-9, admitted under A.3.2 as a description of CrossReferenceUpdateMethod-3
  actingSystemRoleAssignmentRef: CrossReferenceUpdateAssignment-27, one obtaining work-facing U.SystemRoleAssignment held by BuildRunner-4
  transformationRef: PublicationCarrierChange-27, independently admitted under A.3.4 from the build boundary, the before/during/after carrier-state facts below, and the bounded case-local continuity rule
  workOccurrenceRef: DocumentBuildWork-27, independently admitted under A.15.1 from its performance history, enacted CrossReferenceUpdateMethod-3, temporal extent, and containing-System relation; because this case claims exact assignment-bound attribution, F.6 afterward relates the already admitted Work to CrossReferenceUpdateAssignment-27
  evidenceRelationRefs: BuildLogEvidenceRelation-27, one exact A.10 evidence-provenance relation supporting the DocumentBuildWork-27 occurrence claim
  strongerOwnerRefs: E.24.PUB PublicationFormBearingRelation for the before/after bearing facts; bounded case-local PublicationFile-17 continuity rule, not E.24.PUB; A.1 recognition of BuildRunner-4; A.13 performer core including A.2.1 CrossReferenceUpdateAssignment-27; A.15.1 DocumentBuildWork-27; F.6 performed-under-assignment relation; A.7 carrier/episteme distinction; A.3.1 CrossReferenceUpdateMethod-3; A.3.2 BuildScriptEpisteme-9; A.3.4 PublicationCarrierChange-27; A.10 BuildLogEvidenceRelation-27

Before the boundary, exact PublicationFormBearingRelation(PublicationFile-17, CrossReferencePublicationForm-26) obtains and the borne form contains stale form-level link addresses. During the boundary, the same open file object remains in place while its link-address state is rewritten; the build log records no replacement event. After the boundary, exact PublicationFormBearingRelation(PublicationFile-17, CrossReferencePublicationForm-27) obtains and the borne form contains the refreshed addresses. Those facts, the build-open/build-close boundary, and the case-local continuity rule ground PublicationCarrierChange-27 under A.3.4. They do not decide episteme identity: if claim content, EntityOfConcern, or the effective reference scheme changed, C.2.1 identifies another episteme and any historical continuation needs a separately governed edition relation.

The document does not act. The build script is the exact MethodDescription episteme in this case, not the acting entity or the Method by form. An episteme-edition case instead identifies predecessor and successor epistemes plus their exact edition relation. A reference-relation case instead identifies one exact relation occurrence and its direct governor. Each variant receives its own account; neither is inserted as an alternative value in this frame's singular fields.

#Lathe And Workpiece

Source wording: "the lathe makes the workpiece, so the workpiece belongs to the lathe during manufacturing."

Recovered A.12 use:

ActingSideExternalization@Machining:
  changedSubjectRef: Workpiece-8, the exact continuing U.Holon identified under A.1 for this claim
  actingEntityRef: Lathe-3
  actingSystemRef: Lathe-3, the same entity after it satisfies the complete A.1 U.System criterion
  actingSystemA13CoreRef: A.13 core for Lathe-3 as precise performer in this action, including MachiningAssignment-8 as the same obtaining assignment
  actingSystemRoleAssignmentRef: MachiningAssignment-8, one obtaining work-facing U.SystemRoleAssignment held by Lathe-3
  transformationRef: MachiningTransformation-8, independently admitted under A.3.4 as a bounded change of Workpiece-8
  workOccurrenceRef: MachiningWork-8, independently admitted under A.15.1 from its performance history, enacted Method, temporal extent, and containing-System relation; because this case claims exact assignment-bound attribution, F.6 afterward relates the already admitted Work to MachiningAssignment-8
  strongerOwnerRefs: A.1 identities of Workpiece-8 and Lathe-3; A.13 performer core including A.2.1 MachiningAssignment-8; A.15.1 MachiningWork-8; F.6 performed-under-assignment relation; A.3.4 MachiningTransformation-8

MachiningWork-8 and MachiningTransformation-8 are independently identified; this account asserts no work-to-change relation between them. The additional sentence needed for a positive crossing claim is: "Lathe-3 transmits cutting force to Workpiece-8 during MachiningTransformation-8." No current FPF rule in this case defines the required relation kind, obtaining predicate, applicability, and occurrence identity for that sentence. Result: [A.6.RCD](/generated/patterns/A.6.RCD) missing-governor[receiving use: decide whether this force-transfer claim supports a boundary-crossing explanation without a parthood inference; participants: Lathe-3 and Workpiece-8; missing predicate or relation declaration: direct force-transfer or crossing relation]; holonBoundaryCrossingRelationRef stays unfilled. Fixture, control, and material-removal claims likewise need exact participants and a direct predicate or declaration that defines and tests each relation. Recover an exact defining or constraining ClaimGraph only when its identity materially changes interpretation, comparison, migration, conflict, publication, or reuse. Neither the independently identified Work nor transformation establishes parthood; use A.14 or another exact part-whole rule only for a separately supported part-whole claim.

#Bias-Annotation

#Conformance Checklist

#Common Anti-Patterns and How to Avoid Them

#Consequences

Positive consequences:

• Self-action claims become inspectable without denying real internal regulation.
• A.12 stays thin and does not duplicate transformation, method, work, role, evidence, or part-whole ontics.
• Epistemes and publications stop acting by wording.
• Internal control loops, build scripts, and automated changes become easier to audit.
• Manufacturing, teaching, measurement, repair, and control examples no longer imply holonic containment by default.

Costs:

• Compact "self-" sentences need unpacking before use.
• Some diagrams need one more internal distinction between acting and changed positions.
• Evidence cannot be accepted merely because the acting system produced a success message.

#Rationale

Engineering and scientific models need a recoverable acting side for changes. Control, cybernetics, constructor-theory-style transformation talk, software automation, and assurance practice all penalize models where the same undivided object is cause, changed object, method, work occurrence, and evidence source.

FPF keeps that discipline without overbuilding A.12. The transformation ontic lives in A.3.4; Method and Work live in A.15 and A.15.1; a direct assignment species and its occurrence live in A.2.1; a relation among exact local system-role kinds lives separately in A.2.7; Work attribution lives in F.6; evidence lives in A.10; and part-whole admission lives in A.1, A.14, and C.13. A.12 supplies only the acting-side split needed before those patterns can be used cleanly.

#SoTA-Echoing

#Relations

• Builds on: A.1 for holon and System admission, A.2.1 for a directly declared assignment species and its obtaining occurrence, A.2.7 for relations among exact local system-role kinds, and A.3.4 for bounded transformation.
• Coordinates with: A.10 for evidence, A.14 and C.13 for part-whole claims, A.15 and A.15.1 for method and work, C.2.1 and E.17 for episteme and publication cases, and B.2.5 for supervisor-subholon feedback relation.
• Does not own: transformation occurrence evidence, work success, evidence independence, part-whole admission, MHT declaration, or the architecture of the larger holon.

#A.12:End

#The Agential Role & Agency Spectrum

“Agency is not a kind of thing; it is a way some systems operate.”

#Intent & Context

The concept of "agency"—the capacity of an entity to act purposefully—is central to engineering, biology, and AI, yet it remains one of the most overloaded and ambiguous terms. Without a precise, falsifiable, and substrate-neutral definition, models of autonomous systems risk descending into "self-magic," where actions have no clear cause and accountability is lost.

This pattern builds directly on the FPF Kernel. A.1 establishes that the acting holder must be a U.System. A.2 and A.2.1 distinguish a local system-role kind, classification by that kind, and an obtaining occurrence of a directly declared U.SystemRoleAssignment species. A.12 supplies the acting-side externalization principle.

The intent of this pattern is to:

1. Define agency not as an intrinsic type of holon, but as an assignment claim: an exact local agential system-role kind is assigned to a U.System through an obtaining U.SystemRoleAssignment.
2. Introduce a measurable, multi-dimensional spectrum of agency via a dedicated agency-characteristic profile, moving beyond a simple binary "agent/not-agent" switch.
3. Provide a clear, didactic grading system that allows engineers and managers to assess and communicate the Agency Grade of any system in a consistent, evidence-backed manner.

#Problem

If agency is treated as a monolithic, intrinsic property or a mere label, four critical failure modes emerge, undermining the rigor of FPF:

1. Episteme-as-Actor: Models might incorrectly assign agency to knowledge epistemes or publications (U.Episteme), leading to nonsensical claims like "the specification decided to update the system." This is a direct violation of Strict Distinction (A.7).
2. Type Inflation: Introducing a root agent kind alongside U.System and U.Episteme would violate Ontological Parsimony (C-5). The same System may qualify for an agential system-role kind and receive an assignment in one working situation but not another. The agency claim states its scope and window separately; a root type cannot express these differences.
3. Unfalsifiable Claims: Without a measurable basis, "agency" becomes a subjective label. A team might call their system an "agent" for marketing purposes, but this claim has no verifiable meaning and cannot be audited, violating Evidence Graph Referring (A.10).
4. The Binary Trap: A simple "agent/not-agent" classification is too coarse. It fails to distinguish between a simple thermostat, a predictive cruise control system, and a strategic, self-learning robotic swarm, even though their cognitive capabilities differ by orders of magnitude.

#Forces

#Solution

FPF's solution is threefold: establish agential participation through an obtaining system-role assignment, measure agency with a dedicated Characterization, and provide a didactic summary through a graded scale.

#The Core Definition: Agential participation through an exact system-role assignment

An ordinary-language "agent" is not a fundamental FPF type. When a precise agency claim is needed, name four things:

1. the acting holder recognized as a U.System;
2. the exact local agential system-role kind whose membership criterion the holder satisfies;
3. an occurrence of a directly declared U.SystemRoleAssignment species that assigns that kind to the holder and actually obtains; and
4. any claim scope, working situation, and time window needed by the intended use, kept separate from the assignment's identity.

This keeps a useful ordinary word without creating a universal Agent or AgentialRole kind. Classification by the local kind does not by itself establish an assignment or performed Work. Because the holder must be a U.System, an episteme cannot become the acting holder of this assignment.

#Local Agential System-Role Kinds and Their Specializations

• Local agential system-role kind: A practice or source may define a local kind whose stable work-facing contribution is goal-directed action. The kind classifies candidate Systems under its own criterion; it is not a universal root kind, an assignment occurrence, or Work.
• Specialized agential system-role kinds: A local practice may distinguish transformation, observation, planning, or another contribution when it supplies a real criterion for the distinction. An assignment to one such kind establishes only that assignment; any transformation, observation, plan, or performed Work still needs its own claim.

#Measuring Agency: The Agency Characteristic Profile and the Spectrum

Agency is not a binary switch; it is a multi-dimensional spectrum of capabilities. A.13 defines the current domain profile and attaches its measurable characteristics to the exact holder and agency claim; A.17, A.18, A.19, C.16, and A.10 govern characterization, measurement, and evidence. Planned C.9 Agency Characteristic Profile may later consolidate that profile but supplies no current definitions or governing force.

The agency-characteristic profile is grounded in contemporary research (e.g., Active Inference, Basal Cognition) and includes the following key characteristics. Each measurement names its exact holder and, where relevant, its task family or work target, claim scope, working situation, and time window; A.10 supplies the evidence basis.

1. Boundary Maintenance Capacity (BMC): The ability of the system to maintain its structural and functional integrity against perturbations. (How robust is it?)
2. Predictive Horizon (PH): The temporal or causal depth of the holder's internal model. (How far ahead can it "see"?)
3. Model Plasticity (MP): The rate at which the agent can update its internal model (U.GenerativeModel) in response to prediction errors (U.Error). (How quickly can it learn?)
4. Policy Enactment Reliability (PER): The probability that the agent will successfully execute its chosen U.Method under operational conditions. (How reliably does it do what it decides to do?)
5. Objective Complexity (OC): A measure of the complexity of the U.Objective the holder can pursue, from simple set-points to abstract, multi-scale goals.

#Task-family specialization claims

When Work shifts to a new TaskFamily, describe evidence-backed specialization for that task family and work target rather than greater intelligence in general. Keep the task family, work target, claim scope, working situation, measurement window, work-measure threshold, adaptation budget, and provenance basis as separate values. The same holder may show different specializations for different task families without becoming a new U-kind; the claim here is time-to-usable specialization for the stated task family and target.

Low-human-overlap or newly discovered task families remain admissible when the task family, evidence basis, and reuse window are explicit by value.

#The Agency Grade (Didactic Layer)

While the multi-dimensional agency-characteristic profile is essential for formal assurance, engineers and managers need a simpler, at-a-glance summary. The Agency Grade is a non-normative, didactic scale from 0 to 4 that synthesizes the profile into an intuitive autonomy grade.

Crucial Distinction: The agency-characteristic profile is the normative evidence. The Grade is a pedagogical shortcut. A holder cannot claim an Agency Grade without having a corresponding, auditable characteristic profile to back it up.

#Archetypal Grounding

The cases below apply the same test to individual and collective Systems, and then contrast them with a knowledge artifact. Each positive case names the holder, one illustrative local agential system-role kind, and one distinct assignment occurrence that relates that holder to that kind. The characteristic sketch and grade remain separate claims. The names are didactic examples, not a universal AgentialRole vocabulary.

Key takeaway from grounding: The same ontology works for a thermostat, a predictive controller, a learning System, and a collective System: classification by a local kind and an obtaining assignment are both stated, while scope, situation, Work, evidence, profile, and grade remain separate. An exact ISO claim episteme may be cited in an A.10 evidence-use or B.3 reliance claim when that relation actually obtains; its file carrier merely bears a publication form. Neither the citation nor the publication acts.

#Conformance Checklist

To ensure the agency model is applied rigorously and consistently, all FPF publications must adhere to the following normative checks.

#Consequences

#Rationale

This pattern's value comes from its synthesis of contemporary, post-2015 research into a single, operational model.

• Grounded in Science: The move away from a binary, type-based view of agency towards a graded, spectrum-based model is directly aligned with modern research in Active Inference (Friston et al.), Basal Cognition (Fields, Levin), and evolutionary cybernetics. The agency-characteristic profile provides a direct, practical implementation of these ideas.
• Ontologically Sound: Agential participation uses an exact local system-role kind and a separately obtaining U.SystemRoleAssignment instead of a new base type. Holder, kind, classification, assignment, performed Work, claim scope, and time window remain distinct. This follows Strict Distinction (A.7) without making the practitioner carry a universal context tuple.
• Pragmatic and Actionable: The pattern is designed for engineers and managers. The Agency Grade provides a quick communication tool, while the underlying agency-characteristic profile provides the detailed, auditable data needed for formal assurance and risk management. This duality satisfies both Didactic Primacy (P-2) and Pragmatic Utility (P-7).

In essence, this pattern does not invent a new theory of agency. It distills and operationalizes the emerging scientific consensus, packaging it into a rigorous, falsifiable, and practical tool for the FPF ecosystem.

#Relations

• Builds on:
  • A.1 Holonic Foundation: Establishes that only U.Systems can be bearers of behavioral roles.
  • A.2 System-Role Kinds and Assignments: Distinguishes an exact local system-role kind, classification by that kind, and an obtaining U.SystemRoleAssignment.
  • A.12 External Transformer: Work by an acting holder is modeled using the external transformer principle.
• Coordinates with:
  • B.2 Meta-Holon Transition (MHT): A significant jump in the agency-characteristic profile of a collective can trigger an MHT.
  • B.3 Trust & Assurance Calculus: The agency-characteristic profile provides crucial inputs for assessing the reliability and safety of an autonomous system.
  • D.2 Multilevel Ethics For System-Holon Work: The Agency Grade is used to determine the moral-responsibility posture and accountability assigned to a system.
• Future consolidation:
  • Planned C.9 Agency Characteristic Profile may later consolidate the characteristics (BMC, PH, etc.), but provides no current definitions or governing force; the current profile is defined here and measured under A.17/A.18/A.19/C.16/A.10.

#A.13:End

#Advanced Mereology: Components, Portions, Aspects & Phases

Type: Kernel mereology and part-whole relation discipline pattern Status: Stable

At a glance. Use A.14 when wording such as part, member, portion, aspect, or phase could hide different claims. Recover whether the subject is a constructive part, belongs to a collection, is an amount of the same stuff, is one aspect, or is the same carrier during a proper time interval before downstream architecture, Work, assurance, or U-kind admission relies on it.

Use this when. Use this pattern when a text says that something is part of something else, belongs to a collection, is some amount of the same stuff, is an aspect of one holon, or is the same holon during a time interval, and choosing the wrong relation would change identity, aggregation, responsibility, evidence, or structural grounding.

What goes wrong if missed. Teams count members as components, portions as components, aspects as separate wholes, or phases as separate objects; constructive traces and Working-Model relation claims then ground the wrong EntityOfConcern.

What this buys. One human-facing relation catalogue that keeps constructive components and constituents, measured portions, bearer-dependent aspects, proper temporal phases, and collection belonging under each collection's own rule distinct without inventing a catch-all aspect or member vocabulary.

Not this pattern when. Not this pattern when the current question is only a selected Characteristic (C.16/A.19), viewpoint or view (E.17.0/E.17.1), representation or projection (C.29 or its direct projection pattern), temporal claim without a PhaseOf relation (C.27.TA), constructive trace (C.13), Working-Model assurance grounding (B.3.5), meta-holon transition (B.2), or general U-kind admission (E.24.UK).

#Problem frame - why an advanced mereology?

Before choosing a relation, identify the candidate part and whole, or the entity and collection. Use their normal identity rules. A local system-role kind, Method, Work occurrence, view, or trace does not become a structural part merely because the text calls it one; use its own pattern unless a separate part claim is established.

Four recurring questions then matter:

1. Quantities vs. parts. Engineers routinely need “some of the fuel”, “the first 10 pages”, or “a 30% subset of data”. This is not a component; it is a portion of a stuff-like whole, governed by measures and conservation.

2. Selected concern vs. structural aspect. Engineers also say “the thermal aspect”, “the safety view”, or “the inspection slice”. A Characteristic, viewpoint, representation, selected partition, or time window does not become a world-side part by that wording. AspectOf is used only for a bearer-dependent structural part distinguished under a named facet rule.

3. Change vs. replacement. “The prototype before calibration” may be a proper temporal restriction of one unchanged pump. By contrast, “v2 of the spec” first opens C.2.1 identity and, for two different epistemes, its independent edition-continuity test; “shift 1 vs. shift 2” first opens A.15.1 Work-part or occurrence law. None of those labels selects PhaseOf by itself.

4. Belonging vs. construction. “Vehicle 12 belongs to Fleet North” uses the fleet's own rule. That sentence alone makes neither the vehicle a constructive part nor the fleet an acting System, and it does not prohibit either separate claim.

#Problem — what breaks without these distinctions?

If we only have “generic partOf” plus Component/Constituent, five classes of errors appear:

1. Conservation errors. Treating “20 L of fuel from Tank A” as a component leads to nonsense: adding and removing such “components” does not respect quantities; Γ_sys proofs violate Σ-balance.

2. Aspect creation by wording. A selected Characteristic, view, projection, partition rule, dashboard slice, or concern label is turned into a world-side part without identifying the aspect, bearer, facet rule, or identity condition.

3. Temporal smearing. Flattening “before/after” for one enduring carrier into a timeless whole collapses history; treating two changed epistemes or two Work occurrences as temporal pieces of that carrier collapses identity and occurrence history. Γ_time and Γ_method cannot repair either mistake after the fact.

4. Identity confusion. Modelling a “new version” as a component or phase lets a label decide identity. For an episteme, first compare the C.2.1 identity triple and then test edition continuity separately; for another enduring holon, apply its direct identity rule to determine whether the same individual persists or a reidentification question opens.

5. System-role leakage. A local system-role kind, assignment, or relation-position label is put into a part tree (“the PumpRole is part of the plant”), making structural reasoning brittle.

#Forces

#Solution — extend the mereology catalogue, keep it clean

A.14 defines three direct sub-relations of partOf and re-affirms the firewall between mereology and neighboring claims:

1. PortionOf — a measured part of a whole under one extensive measure and boundary rule.
2. AspectOf — a bearer-dependent structural part distinguished under a named facet rule.
3. PhaseOf — the same carrier restricted to a proper time interval.
4. Keep local kinds, Methods, and Work out of structural part trees. Do not treat a local system-role kind or a Method as a structural part. A separately identified System or Episteme may have its own direct part relation; use method-composition patterns for submethods and A.15.1 for Work parts and occurrences.
5. Use the collection's own belongs-to rule. State who or what may belong, what makes belonging begin and end, and how recurrence and past belonging are handled. FPF does not use one public MemberOf relation for unlike collections. Belonging alone establishes neither holonhood nor parthood, and it does not rule out a separately grounded constructive part relation after all six A.1 matters pass.

The classical pair ComponentOf (structural, discrete) and ConstituentOf (conceptual, logical/epistemic) remain as in the kernel; A.14 only clarifies how to tell them apart from Portion/Phase (§ 6).

#Formal cores (normative semantics)

#PortionOf — metrical part of a measurable whole

Intent. Capture “some of the same stuff/extent”, governed by a measure that adds up.

Applicability. Any U.Holon that carries an extensive measure μ on the chosen scope (examples: mass, volume, length‑of‑text, byte size, wall‑time budget).

Primitive. PortionOf(x, y) means: x is the same kind of stuff/content as y, but less.

Axioms (A14‑POR‑*)

• POR‑1 (Partial order). PortionOf is reflexive, antisymmetric, transitive on its domain.
• POR‑2 (Metrical dominance). If x ProperPortionOf y then 0 < μ(x) < μ(y) for the agreed μ.
• POR‑3 (Additivity on disjoint portions). If PortionOf(x,y), PortionOf(z,y), and x ⟂ z (the two portions do not overlap), and their join is admitted under the same measure and boundary rule, then μ(x ⊔ z) = μ(x)+μ(z) and PortionOf(x ⊔ z,y). ProperPortionOf additionally requires the joined measure to remain strictly below μ(y); a join equal to the whole is PortionOf but not ProperPortionOf.
• POR‑4 (Kind integrity). x and y must share the same measure kind and unit (or a declared conversion).
• POR‑5 (Boundary compatibility). For physical wholes, the whole’s boundary encloses the union of its portions; cross‑boundary “leaks” are interactions, not portions.

Didactic tests. ✔ “5 kg from a 20 kg billet” — PortionOf. ✔ Two disjoint 5 kg cuts from the same 20 kg billet have a 10 kg join under the same mass unit and boundary rule; that join is still a ProperPortionOf the billet. ✔ “Pages 1–10 of the report” — PortionOf (μ = page or token count). ✘ “The pump module of the plant” — ComponentOf, not PortionOf. ✘ “The Methods section of the paper” — ConstituentOf, not PortionOf.

#PhaseOf — temporal part of the same carrier

Intent. Capture “the same holon during a sub‑interval”, preserving identity through change.

Applicability. Any U.Holon that persists across time with a recognised carrier identity.

Primitive. PhaseOf(x, y) means: x is y restricted to a proper time interval.

Axioms (A14‑PHA‑*)

• PHA‑1 (Strict temporal parthood). PhaseOf is irreflexive, asymmetric, and transitive on proper temporal restrictions of one unchanged carrier. In particular, PhaseOf(y,y) is false: a whole-lifetime or self-reference is not a proper temporal part.
• PHA‑2 (Proper interval and same carrier). PhaseOf(x,y) requires the interval of x to be a proper sub-interval of y's interval and the carrier-identity rule to hold throughout both. It does not require x to be a maximal cell of a partition.
• PHA‑3 (Nesting and overlap are allowed). Temporal restrictions of the same carrier may nest or overlap. A week may be part of a year-long phase, and a diagnostic window may overlap a calibration window. Those facts are not contradictions and do not by themselves select an aspect or partition.
• PHA‑4 (Selected partition is an additional claim). When a use needs exhaustive non-overlapping cells, declare one carrier, one interval to be covered, one analysis aspect or partition rule, and the selected family of PhaseOf values. Only cells of that same explicitly selected partition must be pairwise non-overlapping and jointly cover the declared interval. Another aspect or rule may select a different, overlapping family.
• PHA‑5 (Identity through change). Properties may vary between phases, but the carrier’s identity criteria hold continuously (e.g., same serial number, same legal identity, same theorem statement).
• PHA‑6 (Escalation to MHT). If identity criteria break (e.g., metamorphosis with new objectives), declare a Meta‑Holon Transition (B.2) rather than a PhaseOf.

Didactic tests. ✔ “PumpUnit#3 before calibration” — PhaseOf(Pump#3_pre, Pump#3). ✔ If PhaseOf(Pump#3@week-32, Pump#3@2026) and PhaseOf(Pump#3@2026, Pump#3), transitivity also gives PhaseOf(Pump#3@week-32, Pump#3). A high-vibration diagnostic window may overlap a calibration window for the same pump; neither is thereby a cell of one selected partition. ✔ “Specification episteme E during τ₂”, with the C.2.1 identity triple unchanged and a proper interval current — PhaseOf(E@τ₂, E). ✘ “Spec v2” — if a C.2.1 discriminator changed, identify another episteme and test EpistemeEditionRelation(E_v1,E_v2) separately; the label proves neither identity nor continuity. ✘ “Shift 1 of the same batch run” — use A.15.1 TemporalPartOf_work, EpisodeOf_work, OperationalPartOf_work, or another exact Work-part or occurrence relation whose predicate obtains. ✘ “Prototype vs. production unit” — likely different carriers; use ComponentOf/ConstituentOf or MHT per criteria.

#AspectOf — bearer-dependent structural part under one named facet rule

Intent. State that one identified bearer-dependent part is an aspect of its bearer without turning a Characteristic, viewpoint, representation, concern, partition, or time window into a part.

Participants and qualifier. x and y occupy the U.Holon parthood domain: x is the aspect and y its bearer. Each must already satisfy its applicable holon-kind and identity rule; AspectOf does not grant systemness, agency, or independent-whole status. The qualifier f names the facet rule used in this occurrence; it does not introduce a universal U.Facet kind.

Primitive. AspectOf(x, y; f) means: x is the bearer-dependent structural part of y distinguished under facet rule f. The notation shows the required qualifier; the public sentence may remain “x is an aspect of y under the f rule.”

Obtaining conditions and properties (A14-ASP-*).

• ASP-1 (Identified occurrence). Name x, y, f, the relation occurrence, and the aspect-identity rule. The facet rule states what distinguishes x from the rest of y and what change preserves or ends this aspect.
• ASP-2 (Structural dependence). AspectOf(x,y;f) implies ut:StructPartOf(x,y), x != y, and asymmetry for that occurrence. It implies none of ComponentOf, ConstituentOf, PortionOf, PhaseOf, collection belonging, or independent systemhood.
• ASP-3 (Facet-local and non-transitive). An occurrence under f gives no occurrence under another facet. AspectOf is not assumed transitive through another bearer or facet; state every relied-on relation directly.
• ASP-4 (Bearer and aspect identity). If the bearer is reidentified, or f and the aspect-identity rule no longer identify x, the old occurrence ends. A changed view, diagram, name, or measurement does not by itself change the world-side occurrence.
• ASP-5 (Neighbor boundary). A measured quality routes to C.16/A.19; a viewpoint or view to E.17.0/E.17.1; a representation or projection to C.29 or its direct projection pattern; a selected temporal window to PhaseOf or C.27.TA; a selected partition to the pattern governing that structure. None creates AspectOf by selection alone.

Didactic tests.

• ✓ In Reactor-7, the thermal-boundary rule distinguishes ThermalEnvelope-7 as the connected enclosure of insulation panels, seals, and boundary interfaces that constrains heat transfer across the reactor boundary. ThermalEnvelope-7 is identified by the continuing enclosure under that rule, not by a fixed panel list. AspectOf(ThermalEnvelope-7, Reactor-7; thermal-boundary) obtains while that enclosure and Reactor-7 continue. Replacing one panel under the same rule preserves the aspect; dismantling the enclosure, replacing the facet rule with a different boundary, or reidentifying Reactor-7 ends the occurrence. A changed temperature reading or dashboard view does not.
• ✗ “Safety is an aspect of the design” when safety is only a Characteristic, concern, viewpoint, or heading. Recover that actual claim first.
• ✗ “Pump-7 during warm-up is its thermal aspect.” Use PhaseOf for the proper temporal restriction and A.19 for a measured thermal Characteristic when those claims obtain.

#CT2R-LOG and Compose-CAL handshake

• A direct structural parthood claim is usable without this assurance handshake. If the publication elects B.3.5 or a named current requirement demands it, link the claim through tv:groundedBy to its applicable current C.2.1 Γ_m.sum or Γ_m.slice construction-trace episteme and declare validationMode=axiomatic. The direct relation pattern decides whether the occurrence obtains and how it is identified; the relevant entity pattern decides identity through change. The trace only reports that basis.
• AspectOf uses one current C.13 slice trace when that assurance branch is elected. The trace names the aspect, bearer, facet rule, relation occurrence, and identity conditions; it creates none of them.
• PhaseOf is temporal parthood and shall not be grounded through Γ_m. Its assurance follows the same-carrier and proper-interval criteria, the separately declared selected-partition rule when one is claimed, and Γ_time ordering (B.1.4).
• A collection's own belongs-to relation remains distinct from constructive parthood (CC-MEM-2). State its participants, what makes it obtain, and whether later belonging is the same occurrence or a new one under the collection's pattern. A direct claim needs no B.3.5 fields. If B.3.5 assurance is elected, link validationMode=axiomatic to one current C.13 set trace that reports the relation that already obtains. The trace supports neither a ComponentOf inference nor a universal prohibition on separately grounded parthood.

Two quick identity tests apply before relying on a trace. The same listed constituents can form a different whole when their direct assembly relations or rule differ. Conversely, a permitted constituent replacement can preserve the same whole. An equal input list, a repeated trace, or validationMode=axiomatic decides neither case.

#Choosing the right relation (decision table)

Firewall reminder. If the sentence is about system-role-kind classification or assignment, how action is done, or what happened when, use A.2/A.2.1, A.3.1, or A.15.1 as appropriate. For an episteme, use A.14 for content parthood or a proper interval of one unchanged C.2.1 identity; changed claims, EntityOfConcern, or effective reference scheme identify another episteme, and any historical continuation uses C.2.1 EpistemeEditionRelation only when its predicate obtains.

#Archetypal Grounding

#Bias-Annotation

A.14 corrects parthood bias: ordinary words such as part, member, phase, aspect, section, version, module, function, role, and ingredient can hide different objects or relations. Recover whether the source means component, constituent, measured portion, bearer-dependent aspect, proper temporal phase, collection belonging, local system-role-kind classification, assignment, Method, Work, evidence, or transformation.

It also corrects analysis and representation bias. A Characteristic, viewpoint, view, projection, selected partition, dashboard slice, diagram, table row, or time window may describe or foreground something about a bearer without becoming a world-side structural aspect. AspectOf begins only after the aspect, bearer, facet rule, relation occurrence, and aspect identity are established. Publication or construction traces report such a claim; they do not create it.

#Conformance Checklist - type guards

#Global firewall and scope

#PortionOf guards

#PhaseOf guards

#AspectOf guards

#Grounding and validation (normative)

Note. Property names and trace semantics are defined in CT2R-LOG and Compose-CAL.

#Collection belonging and separately grounded parthood

#CT2R‑LOG handshake (Working‑Model → Assurance)

#Relation-use decision procedure

Step 0 — Recover the claim. If the sentence concerns system-role-kind classification or assignment, Method, Work, evidence, a Characteristic, viewpoint, view, projection, partition, or temporal claim without parthood, use that direct pattern. A.14 is not selected merely because ordinary speech says part or aspect.

Step 1 — Is it measured stuff or extent? If yes, use PortionOf. Declare μ, unit, boundary, and additivity conditions.

Step 2 — Is it a discrete integrated or conceptual part? If yes, use ComponentOf or ConstituentOf. Do not use PortionOf merely because the part can also be measured.

Step 3 — Is it the same carrier during a proper sub-interval? If yes, use PhaseOf after the carrier-identity and interval tests. Another episteme or Work occurrence uses its own identity and relation patterns.

Step 4 — Is it a bearer-dependent structural aspect? Use AspectOf only after naming the aspect, bearer, facet rule, relation occurrence, and aspect-identity rule. If the source names only a Characteristic, viewpoint, view, projection, selected partition, concern, or time window, return that actual claim instead.

Step 5 — Does the entity belong to a collection? Use the belongs-to rule defined for that collection after naming the entity, collection, beginning, ending, recurrence, and history conditions. Infer neither part nor holonhood and do not infer that separately grounded parthood is impossible. If collective action is current, apply all six A.1 matters separately.

Quick spot-tests.

#Interplay with Γ‑flavours (how these relations behave under aggregation)

#Common Anti-Patterns and How to Avoid Them

• Member as component. A person, team, document, or object belongs to a collection and is then counted as structurally integrated.
• Aspect by label. A Characteristic, concern, viewpoint, view, projection, partition, heading, dashboard slice, or time window is called an aspect and entered into a part tree. Recover the actual claim; require the full AspectOf occurrence when structural parthood is intended.
• System-role expression as part. A local kind, assignment, or relation position is put into a part tree instead of using its direct pattern.
• Method as part. A Method, recipe, or algorithm is treated as a structural component instead of using Method, MethodDescription, Work, or transformation patterns.
• Portion without measure. Some fuel, data, time, or text is named as a portion without measure kind, unit, boundary, and additivity conditions.
• Phase as replacement or lineage. Another episteme, version label, or Work segment is treated as PhaseOf without applying C.2.1 or A.15.1.
• Diagram or trace as relation. A breakdown, graph, table, construction trace, or validation mode is used as proof that parthood or identity obtains.

#Pedagogy aids (non-normative)

Two-minute checklist for practitioners

1. What subject and relation does the sentence claim?
2. Does every PortionOf have a declared extensive measure, unit, boundary, and additivity condition?
3. Does every AspectOf name the aspect, bearer, facet rule, occurrence, and identity rule—and avoid replacing a Characteristic, view, projection, partition, or time window?
4. Is every PhaseOf a proper interval of one unchanged carrier rather than another episteme or Work occurrence?
5. Does every collection claim use its own belongs-to rule without inferring or prohibiting a separate part relation?
6. Are local system-role kinds, assignments, Methods, Work, views, and traces kept outside the part tree unless an independently admitted carrier and direct part relation are current?

#Consequences

Benefits

• Predictable composition. Additive portions, facet-local aspects, same-carrier phases, and explicit collection rules keep unlike claims separate.
• Analysis does not create ontology. Characteristics, viewpoints, views, projections, partitions, and time windows remain usable without being turned into structural parts.
• History without confusion. Aspect and phase identity changes are explicit; collection history stays with the collection's rule.
• Readable first use. A practitioner can state the direct component, constituent, portion, aspect, phase, or belongs-to sentence before any elected assurance account.

Trade-offs and mitigations

• More distinctions. Authors must name a measure for PortionOf, a facet and identity rule for AspectOf, or a proper interval and carrier identity for PhaseOf. The decision table and two-minute checklist keep the first move short.
• Aspect judgement. Distinguishing a structural aspect from a Characteristic, view, projection, or temporal claim requires judgement; neighboring patterns provide the stop and route.
• Optional assurance effort. sum, slice, and set traces are added only when B.3.5 or another named current requirement elects them.
• Escalation discipline. When bearer or carrier identity fails, use the direct reidentification pattern rather than preserving an AspectOf or PhaseOf occurrence by label.

#Rationale

A.14 exists because part-whole words carry identity, aggregation, measure, facet, time, and assurance commitments. The pattern keeps those commitments in the direct relation instead of letting everyday nouns, concerns, views, diagrams, or breakdown tables decide ontology. Component, constituent, portion, bearer-dependent aspect, proper phase, and collection-belonging claims can then support downstream work without smuggling Characteristics, viewpoints, local kinds, assignments, Methods, Work, or publication claims into mereology.

#SoTA-Echoing

This edition's collection-belonging rule follows the current constructional line: first identify what is being constructed and what gives it identity, then state the relation that actually obtains. It does not import a ready-made universal membership predicate.

#Aspect branch application

For AspectOf, the BORO and CCO rows above supply the constructor-sensitive question: which bearer, facet rule, dependent aspect, and identity conditions make this structural part? Fine's composition-first pressure blocks a bare aspect label from deciding parthood. A.14 adapts that line in A.14:5.3, the decision procedure, and CC-ASP-1 through CC-ASP-4; C.13 slice remains an optional report, not the constructor of the aspect. The serious alternatives are routed rather than renamed: measured Characteristic (C.16/A.19), viewpoint or view (E.17), representation or projection (C.29 or its direct pattern), selected partition, and temporal restriction (PhaseOf/C.27.TA). This route is no worse for correctness and cheaper for a cold reader than a universal aspect kind; its cost is that the author must identify the actual relation before reusing the word.

The resulting collection alternatives are deliberately distinct:

• Selected: an ordinary subject-specific belongs-to sentence plus the collection's own rule.
• Rejected: one generic MemberOf, because it collapses formal inclusion, classification, participation, collection belonging, and constructive parthood.
• Rejected for present public use: one qualified generic collection-belonging predicate, because its qualifiers must recreate every subject rule and make the first move harder.
• Retained as a separate possible claim: constructive parthood, but only when its direct relation obtains and all six A.1 matters pass.

At comparable correctness and temporal adequacy, the selected answer is no worse than the qualified or separately named alternatives and is cheaper for a cold reader and maintainer. A generic predicate looks cheaper only because it omits decisive conditions. The real cost is that A.14 supplies no immediate cross-domain query key for all belongs-to relations; use F.18 to name a narrower relation when repeated query, comparison, or declaration use justifies that extra vocabulary.

The rest of the catalogue retains its own governing source lines:

• Metrical mereology advances motivate PortionOf with explicit μ and Σ-laws, preventing the classic “stuff as components” fallacy.
• Temporal parts and identity through change motivate PhaseOf as transitive proper temporal parthood, with nesting and overlap allowed, partition-specific coverage and non-overlap, and escalation when identity criteria fail.
• Engineering product models, including the ISO 15926 family, pressure authors to keep functional classification, physical product breakdown, and stocks or consumables distinct; A.14 routes those claims to their direct relations instead of one part tree.
• Knowledge-episteme edition histories in contemporary MBSE and open-science practice motivate explicit endpoint identities and provenance-preserving composition. FPF uses the C.2.1 identity triple and independently obtaining EpistemeEditionRelation for distinct editions; A.14 retains PhaseOf only for a proper temporal restriction of one unchanged episteme.

The net effect is a minimal-sufficient catalogue: direct component, constituent, portion, bearer-dependent aspect, phase, and collection-belonging claims stay distinct, while a separately grounded constructive part claim remains possible without another universal relation vocabulary.

Treat this source account as current for this edition. Reopen only the affected A.14 rule if a cited constructional source changes a distinction used here, a newer relation architecture provides the same claim correctness and history at lower reader or maintenance cost, or a direct consumer needs a meaning that the current rule cannot express. Recheck A.14:5.3 and CC-ASP-1 through CC-ASP-4 for an AspectOf change; recheck Solution item 5 and CC-MEM-1 through CC-MEM-3 for a collection-belonging or separately grounded parthood change. An ordinary change to a bearer, facet rule, aspect occurrence, collection rule, belonging occurrence, or optional trace reopens only that claim and its support, not this source decision.

#Relations

• Builds on: A.1, A.7, B.1, B.2, C.13, and B.3.5 for holon identity, strict distinction, gamma-flavour separation, meta-holon transition, constructive grounding, and Working-Model assurance.
• Coordinates with: C.16 and A.19 for measured Characteristics; E.17.0/E.17.1 for viewpoints and views; C.29 and direct projection patterns for representations; C.27.TA for temporal claims; and A.2, A.2.1, A.3.1, A.3.2, A.15, A.15.1, and A.3.4 when wording concerns a local kind, assignment, Method, Work, or transformation rather than parthood.
• Used by: architecture, description, evidence, and U-kind admission patterns when their structural claim depends on a clean parthood relation.

#A.14:End

#System-Role–Method–Work Alignment

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

At a glance. Use this pattern when a team must say which System performed which Work, under which assignment, which Method the Work enacted, and which plan applied without confusing any of those values with a description, capability, record, or result. A precise actual-performer branch first reuses A.13's core, then A.15.1 independently admits the dated Work, and only afterward F.6 uses the same obtaining assignment when precise assignment-bound attribution is current; an agency characteristic profile remains conditional on its receiving use.

Use this when. Separate a local system-role kind, an assignment occurrence that obtains, its holder system, a U.Method, any U.MethodDescription, a U.WorkPlan, a holder U.Capability instance, the capability-fit and evidence claims actually relied on, and dated Work before a schedule, display, document, or familiar label is treated as if it established the whole chain.

Start here when. The team is mixing system classification or assignment with recipe, schedule, capability, or performed Work, often under an ambiguous source word such as role, process, workflow, or activity.

First output. If the team is planning, name the intended U.WorkPlan, intended performer System, local system-role kind, and Method needed by the next decision; do not invent Work or an obtaining assignment. If performance has occurred, first recover the A.13 core and independently admit the dated Work under A.15.1 from its actual history, Method, extent, and containing-System relation. Then, only when precise assignment-bound attribution is current, establish F.6 performedUnderAssignment through the same obtaining assignment. Name only the assignment occurrence, declared species, holder System, and Method needed by this decision. Say plainly that the A.13-qualified holder System performed the Work under that same assignment and that the Work enacted the Method only when both relations obtain. Keep the local system-role kind, MethodDescription, WorkPlan, capability, assertions, records, and results separate in either branch.

Working enactment-alignment sequence. For precise actual performance, recover the A.13 core for the holder System and local agential kind -> recover the same obtaining assignment occurrence and its declared species -> separate Method from MethodDescription, WorkPlan from Work, and capability from performance -> independently admit the dated Work through A.15.1 -> apply F.6 only when precise assignment-bound attribution is current -> state only the relations needed by the next use -> proceed, plan, probe, narrow, use the pattern for another claim, or stop.

Working alignment applications.

1. For a precise actual-performer claim, recover the exact holder System, the local agential system-role kind and criterion, classification, same obtaining assignment, scope, working situation, window, and adequate A.13 core evidence. Add a characteristic profile only when a Grade, autonomy or profile result, criterion-dependent characteristic, or assurance use consumes it.
2. Name the declared assignment species and the occurrence that actually obtains. The species defines the holder and assigned-kind positions; the occurrence supplies their actual values. Add another participant only when it changes the assignment.
3. Name the Method and keep any MethodDescription separate. Name either the intended U.WorkPlan or the actual dated Work occurrence, never one as proof of the other.
4. State performedUnderAssignment and enactsMethod only when their predicates obtain. The holder system performs the Work; neither the kind, assignment, Method, description, plan, nor capability acts.
5. If a visible item is being relied on for a Work, approval, evidence, gate, or release claim before the relation required by that claim is known, use A.15.4; keep only the alignment part here.

Action-pattern protection. This pattern does not classify encountered publications, displays, or cues. It keeps system-role kind, assignment, Method, MethodDescription, plan, capability, performed Work, and records distinct so an engineer-manager can choose the next admissible action. Use A.15.4 for work-relevant appearance-based reliance repair.

Minimum sufficient use. Recover only the values and relations needed by the receiving use. Ordinary orientation can stop at one clear sentence. A reliance-bearing claim may also need exact occurrence identity and extent, the selected source and its currentness, a capability-fit claim, and the evidence or assurance claim actually relied on.

Recovered-reference sufficiency condition. Proceed when every project-side value on which the claim relies is identified by its admitted kind, exact referent, scope, and current window. Otherwise narrow the claim, run a bounded reversible probe, recover the missing relation, or create only the smallest repair request, decision request, prospective WorkPlan entry, or missing-source note needed for the next use.

Ordinary use. “Robot-7 performed InspectionWork-17 under InspectionAssignment-17, and the Work enacted TurbineInspectionMethod” can be enough when the A.13 core, same obtaining assignment, F.6 link, and enactsMethod relation remain recoverable and the receiving use needs no identifiers. A Grade or autonomy profile is not implied.

Reliance-bearing use. Use the fuller frame when assignment identity, assignment state, Method edition, capability fit, plan baseline, approval, evidence, release, or disputed responsibility changes the decision. Responsibility and authority remain separate direct relations; neither follows from a system-role kind or assignment.

Stop condition. Stop once the separation changes no next admissible use and blocks no concrete overclaim about classification, assignment, assignment state, Method, plan, Work, result, approval, evidence, or release.

Admissible-use examples.

Alignment frame in plain terms. The system-role kind says what contribution kind is in question. The assignment says that this system holds that kind in one actual episode. The Method says how the Work is done. The WorkPlan says what is intended. The dated Work occurrence says what happened. Descriptions and records state claims about those values; they are not those values.

What goes wrong if missed. A team collapses classification, assignment, recipe, plan, capability, and performed Work into one fuzzy “process” or “role” label, then mistakes documentation for execution, capability for performance, a schedule for an occurrence, or an assignment for responsibility.

What this buys. A compact trace that answers who performed the Work, under which assignment, which Method the Work enacted, and which separate plan and evidence applied, while leaving every stronger neighboring claim to its direct pattern.

Not this pattern when. Use A.15.1 for one dated Work occurrence, A.15.2 for planning or schedule baselines, A.15.5 for work-entry readiness, A.16 or A.16.1 for a cue that has not become an alignment question, A.6 or A.6.B for boundary or policy wording, E.10.ROLE when role is still unresolved, and A.15.4 when a visible item is being relied on by appearance.

Related pattern contributions. Use A.2 and C.3 to identify exact local system-role kinds, A.2.1 for direct U.SystemRoleAssignment species, A.13 for the precise local agency core and any conditionally consumed profile, F.6 for performed-Work attribution through that same assignment, A.15.1 for dated Work, A.15.2 for WorkPlan epistemes, A.15.3 for declaration-local planned-filling content inside a WorkPlan, A.15.4 for work-relevant reliance by appearance, A.15.5 for work-entry readiness, F.11 to align Method and Work vocabulary across contexts, and F.17 for the human-facing work sheet.

Causal-use work boundary. Counterfactual sampling, randomization, intervention assignment, target-trial emulation, and causal evidence collection can be represented here as Methods, MethodDescriptions, WorkPlans, dated Work occurrences, and their exact assignment and Method relations. A.15 does not make the resulting causal use admissible. Use C.28 for the causal-use question, rung, estimand, separate evidence/identification/estimate/sampling/simulation components, counterfactual-sampling result, support result, and supported and unsupported uses.

Related-record mistakes. A cue, publication, plan, record, result, evidence item, or approval can help locate a value without becoming that value. Recover the dated Work under A.15.1. State a subject-specific production or result relation only under its direct pattern; for a production-work, entity-inception, or production-completion question, A.15.PROD may instead return one local claim or exact blocker. Use A.15.4 only when reliance on an encountered appearance is the problem.

Boundary to coarsened renderings. A briefing, summary, redacted note, or coarsened rendering may orient work. Rely on it for an execution, approval, gate, or evidence question only when the exact sources and relations required by that use remain explicit and reopenable. Use A.6.3.CSC when coarsening itself changes what may be relied on.

Use boundary. A.15 supplies only the system-role–Method–Work alignment needed by the current project question. Send a single occurrence, wording, assurance, evidence, result, or reliance question to the pattern that defines or tests that claim.

Outside-practice result boundary. When one receiving decision or piece of Work needs a bounded result governed by another practice, use A.15.9 to inspect an already-available result before requesting anything new, ask only for the remaining gap, and preserve supplier Method and authority separately from the receiving decision. A.15 keeps the underlying Method, Work, performer, assignment, communication, result, and record distinctions unchanged.

#Problem frame

When the alignment is already clear and ongoing Work still needs one next action chosen from current facts within an applicable domain Method, use A.15.7. It keeps the domain Method, steering Method, deciding System, intended performer, and any later WorkPlan or performed-action claim separate.

Complex work requires several independent distinctions: what a System is; which local system-role kind classifies it; which assignment occurrence obtains and which declared U.SystemRoleAssignment species it instantiates; how Work is done through U.Method; whether an episteme is a U.MethodDescription; which holder capability is relied on; what U.WorkPlan states; which dated Work happened; and which separate assertions, records, results, and evidence concern that Work.

A.15 brings these already defined values together without creating a new process object or redefining their ontologies:

• A.2 and C.3 identify a local system-role kind and any classification judgment. Classification neither creates an assignment nor proves Work.
• A.2.1 identifies an assignment occurrence and its declared species under U.SystemRoleAssignment. The species declares HolderSystemSlot, a declaration-local AssignedSystemRoleKindSlot with its local system-role-kind domain, its predicate and applicability, any additional participants, and its occurrence-identity rule. The occurrence supplies the actual participants and extent. Taxonomy, scheme, signature, assertion, evidence, and interval may interpret or describe the claim; they are not generic participants.
• A.13, A.15.1, and F.6 govern ordered but distinct results. A.13 supplies the exact System, local agential kind and criterion, classification, obtaining assignment, scope, working situation, window, and adequate core evidence; its characteristic profile is conditional. A.15.1 then independently admits dated Work. Only after admission, and only when the receiving use expressly consumes precise assignment-bound attribution, does F.6 relate that Work to the same assignment through performedUnderAssignment. Its holder projection is used only to compare holder equality with the actual performer already recovered through A.13; F.6 identifies neither assignment nor performer. Missing F.6 attribution does not revoke Work membership.
• A.3.1 and A.3.2 keep U.Method distinct from U.MethodDescription.
• A.15.1 and A.15.2 keep actual dated Work distinct from intended WorkPlan and from every record about either.
• A.2.2, A.10, and neighboring direct patterns keep capability-fit claims, evidence use, source currentness, publication, responsibility, authority, access, results, and assurance outside assignment and Work identity.

Use E.10, E.10.ARCH, and E.10.ROLE when source wording such as process, workflow, action, activity, schedule, or role has not yet been resolved. The wording chooses no FPF object by itself. Recover the exact Method, MethodDescription, WorkPlan, Work, Transformation, Dynamics, evidence, gate, source, publication use, participation relation, declaration slot, or ordinary non-technical use that the claim actually needs.

#Problem

Without this alignment, several category errors recur:

1. System-role-kind as part. AuditorSystemRole is placed in structural partOf decomposition although it is a local kind used to classify systems.
2. Description as execution. A recipe, algorithm, SOP, or MethodDescription is treated as proof that Work occurred.
3. Capability as Work. Ability and actual performance are collapsed.
4. Work without attribution. A Work occurrence lacks an exact assignment occurrence, performer projection, or Method relation.
5. Assignment as responsibility or authority. Holding a system-role assignment is treated as if it established a duty, permission, responsibility, authority, or approval relation.
6. Universal assignment record. A permissive root signature hides different direct species and turns taxonomy, scheme, context, or source into generic participants.
7. Actor by association. A kind, assignment, capability, Method, description, plan, or record is made to act. Only the admitted holder system performs Work.
8. Process soup. One overloaded source word stands for classification, assignment, Method, description, plan, Work, result, and record at once.

#Forces

#Solution

Recover the actual values first, then state only the relations needed by the receiving use. A.15 aligns system-role kind, assignment, Method, MethodDescription, capability, WorkPlan, Work, and separate records; it does not create a universal process object or a universal assignment signature.

When source wording points to changing, producing, selecting, deriving, controlling, or maintaining an EntityOfConcern, use E.10.ARCH to recover the object. A workflow graph, process calculus, matrix, category, embedding, or neural representation may describe or serve as a lens over a Method relation structure; it is not automatically a Method, assignment, WorkPlan, or Work occurrence.

#Core entities kept distinct

• Exact local system-role kind. A value such as InspectorSystemRole : U.Kind is admitted under A.2 with C.3 through its U.System candidate domain, operative work-facing membership condition, member/non-member boundary, and continuity rule. It is not a system, assignment, relation slot, capability, Method, Work, responsibility, or authority. A system classification judgment and an assignment occurrence are separate claims.
• U.SystemRoleAssignment. This is the relation family consumed by A.15 and F.6. It has no permissive root RelationSignature. Each direct species declares HolderSystemSlot : U.System, a declaration-local AssignedSystemRoleKindSlot whose ValueKind is one exact local system-role-kind domain, its predicate and applicability, every real additional participant, and its occurrence-identity rule.
• U.Method. The run-independent semantic way of doing. A Work occurrence can stand in enactsMethod(W, M); the Method does not act.
• U.MethodDescription. An already identified U.Episteme whose exact EntityOfConcern is an admitted Method and whose substantive claims say how that Method is done, as judged by A.3.2. Wording, file form, or publication alone establishes no membership.
• U.Capability. The A.2.2 holder-dependent ability instance. Capability statements, evidence, currentness assessments, and fit conditions are separate. Capability proves neither assignment nor performance.
• U.WorkPlan. A U.Episteme about possible future Work, including intended windows, dependencies, performers, and budgets. It does not bring a future Work occurrence into existence.
• U.Work. The admitted kind for concrete dated Work occurrences. One Work individual has its own temporal extent, at least one obtaining A.15.1 enactsMethod relation, and at least one obtaining locally declared containing-system relation. It may stand in further enactment, affected-referent, binding, resource-use, production, and result relations when the receiving use needs those independently obtaining facts. Any log, ticket, assertion, description, or performed-work record is a separate episteme.

Work occurrence and record boundary. Do not add a universal primaryTarget field, a local kind field, or an Operational, Communicative, and Epistemic enumeration to Work identity. Recover the exact affected-referent, transformation, speech-act effect, commitment effect, production, delivery, acceptance, or other relation under its direct pattern. Those adjectives can remain recognition cues; they do not define Work subkinds by enumeration.

Didactic note for managers: the chef analogy. ChefSystemRole is one local system-role kind. A kitchen-assignment species defines the holder and assigned-kind positions and adds shift, station, or commission only when it changes the assignment. A particular assignment fills those positions with the chef System, the kind, and any additional value. A cookbook can be a MethodDescription; the chef's skill can be a capability; a WorkPlan can schedule cooking; and making one souffle on Tuesday is dated Work. Its temporal and resource-use relations can state the 25-minute extent, eggs, butter, and consumed gas, while a kitchen log remains a separate episteme. A restaurant vocabulary or scheme can help interpret the claims without becoming a participant in every assignment. The cookbook, skill, plan, assignment, and log do not cook.

#Canonical relations

graph TD
    subgraph "Direct system-role assignment species"
        H["holder H : U.System"] -- "HolderSystemSlot" --> RA["RA : InspectionShiftAssignment<br/><: U.SystemRoleAssignment"]
        K["InspectorSystemRole<br/>exact local kind"] -- "AssignedSystemRoleKindSlot" --> RA
    end

    subgraph "Method, description, and capability"
        M["M : U.Method"]
        D["D : U.Episteme<br/>A.3.2 membership: U.MethodDescription<br/>EntityOfConcern = M"]
        Cap["C : U.Capability"]
        Fit["capability-fit condition"] -- "tests" --> Cap
    end

    W["W : U.Work"] -- "performedUnderAssignment<br/>holder equality check: RA.Holder = H" --> RA
    W -- "enactsMethod" --> M
    style K fill:#fff2cc,stroke:#d6b656,stroke-width:2px
    style Cap fill:#d5e8d4,stroke:#82b366,stroke-width:2px
    style Fit fill:#d5e8d4,stroke:#82b366,stroke-width:2px,stroke-dasharray: 4 4
    style M fill:#d5e8d4,stroke:#82b366,stroke-width:2px
    style D fill:#f8cecc,stroke:#b85450,stroke-width:2px
    style H fill:#e1d5e7,stroke:#9673a6,stroke-width:2px
    style RA fill:#dae8fc,stroke:#6c8ebf,stroke-width:3px,stroke-dasharray: 5 5
    style W fill:#ffe6cc,stroke:#d79b00,stroke-width:2px,font-weight:bold

The diagram shows a simple direct assignment species. A stronger appointment can declare a real additional participant such as a review commission; that specialized occurrence itself is the U.SystemRoleAssignment. Do not create a weaker generic occurrence beside it.

• Capability fit. A MethodDescription, WorkPlan, or work-admission assertion may require a holder capability threshold. The fit condition tests the holder's U.Capability instance and may cite declared measures, U.Characteristic values, Q-Bundle slots, or architecture-characteristic criteria. It is neither an assignment participant nor a second capability kind.
• MethodDescription membership. D is a U.MethodDescription only when A.3.2 recovers Method M as its exact EntityOfConcern and at least one substantive way-of-doing claim. “D describes M” is shorthand for that constitution and membership result, not another binary relation.
• enactsMethod(W : U.Work, M : U.Method). This relation states which exact Method the dated Work enacts. A.15.1 defines its participant order, predicate, occurrence identity, and multiplicity. It neither attributes a performer nor turns a description into the Method.
• performedUnderAssignment(W : U.Work, RA : U.SystemRoleAssignment). F.6 defines this relation. For a precise actual performer, RA is the same obtaining assignment used by A.13 for the exact action, scope, working situation, and window. It must be an occurrence of a declared assignment species, have the A.13-qualified System as holder, and cover the Work while the species predicate obtains. The assignment is the attribution ground, not the actor. A record may state the relation without constituting it. Read an existing performedBy(W, RA) claim only through the F.6 compatibility boundary after resolving the holder System; do not author new claims with that spelling.

One assignment occurrence continues through the maximal uninterrupted interval in which its direct species predicate obtains for fixed participants. A declared interval, taxonomy, scheme, KindSignature, assertion, evidence item, or selected model-use structure can describe or interpret the claim but does not create the occurrence or become a generic participant.

For a precise performed occurrence, first recover the A.13 core for the exact actual performer System and action, then admit W : U.Work under A.15.1 from its independent occurrence, Method, extent, and containment facts. Only afterward trace W to the same RA through F.6 performedUnderAssignment when the receiving use needs precise assignment-bound attribution, and compare RA.HolderSystemSlot with the already recovered performer; F.6 identifies neither. Trace W to M separately through enactsMethod. Cite a characteristic profile only when conditionally consumed; cite a MethodDescription, plan, capability claim, evidence item, taxonomy, or scheme separately only when the receiving use relies on it. The performer System acts; the kind, assignment, capability, Method, description, plan, evidence, and record do not.