#Strict Distinction (Clarity Lattice)

A.7 · Stable · Part A - Kernel Architecture Cluster

#About this pattern

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

#How to use this pattern

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

Status: Stable

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.

#Keywords

• category error
• EntityOfConcern ≠ Description episteme
• system-role kind and assignment ≠ Work
• MethodDescription ≠ Method ≠ Capability ≠ Work.

#Relations

#Content

#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

---

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