A.7:5 - Solution — The Clarity Lattice (normative distinctions & safe vocabulary)

A.7:5.1 - 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 requires an independently constituted Description episteme, checkable claims, and a named harness, validation, conformance, measurement, or evaluation relation capable of checking them for the stated use. When viewpoint selection affects reliance, preserve or explicitly update the named describing use and its selected viewpoint. Formality, acceptance conditions, a C.16 measurement criterion, and verification practice may contribute under their direct rules. 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. Their publication positions do not by themselves identify the EntityOfConcern, the Description episteme, or a specification-use gate or refinement; readable form alone establishes no evidence, gate passage, work, assurance, or decision force. 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 must satisfy the preceding conjunction under E.10.D2 and the direct pattern that supplies the capable checking relation.

• EntityOfConcern / episteme / publication boundary — EntityOfConcern names the exact item under concern. An independently identified episteme may genuinely concern a document, publication face, or carrier; bearing or publishing this episteme does not by itself make that object its EntityOfConcern. A Description episteme makes claims about its exact item under its effective scheme. Publication faces, forms, units, renderings, and carriers may make it available, but presentation alone establishes neither episteme identity nor specification use, evidence, gate passage, Work, assurance, or decision force. Evidence and any constitutive contribution to those relations remain governed by their direct rules. A.7 establishes the following distinction groups. Use their names and scope exactly as below.

A.7:5.2 - 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.

A.7:5.3 - 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, whose composition is governed by 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: A MethodDescription alone does not establish that its Method was performed. Its claims may support a named claim only through the applicable evidence-use relation; 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.

A.7:5.4 - 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 and obtaining assignment when their identity, extent, or participants are used by the claim, including the A.13 core for precise Work admission. State the admitted assignment species when that relation is current. Precise attribution of an already admitted Work to that assignment remains a separate F.6 claim. 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 recover DesignTeamSelectionSystem as the actual performer with its core basis, then A.15.1 to admit the Work independently from the occurrence facts in :2, including at least one Method actually followed. 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. Keep the core’s admitted assignment species, assigned local kind, extent, and evidence recoverable; add another Method, Capability, or further evidence detail only to the degree used by the audit.

A.7:5.5 - Episteme vs publication carrier and source-currentness record

• Episteme — one C.2.1 knowledge holon identified by its complete claim content, exact EntityOfConcern, and effective ReferenceScheme. Its content may include a claim, model, or requirement set.
• Publication carrier — the physical or digital bearer of an episteme publication or stored representation (file, volume, dataset item).
• Source-currentness record — a record of claims about source currentness for a stated use and conditions, distinct from the source episteme and the carrier bearing the record. Use the applicable A.10/G.11 relations when the receiving evidence, source, or reliance claim depends on them.
• Use: Evidence use relates an exact episteme to the claim for which it is used (A.2.4). Arguments and validity concern its claims; provenance and reproducibility also need the source, production, carrier, or checking conditions on which the particular use depends. Apply A.10 and B.3 only for the provenance, reliance, or assurance claims actually made.

Normative guard: When “we updated the spec” matters to the receiving use, state whether its C.2.1 claim content, EntityOfConcern, or ReferenceScheme changed, a carrier changed, or a source-currentness claim was updated. Name the affected object and its direct relation; a carrier change alone does not establish a new episteme.

A.7:5.6 - 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. Keep the statement with its defining mathematical rule; use C.29 for an actual mathematical-lens use and 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.

A.7:5.7 - Match composition to its subject

• System aggregation and delimitation — use B.1.2:4 to coordinate the independently established parts, crossings and whole-characteristic claims needed by the engineering decision. Each characteristic keeps its own aggregation or inference rule.
• Method composition — use B.1.5 to determine whether constituent Methods and their relations construct one reusable way of doing, including its order and branching.
• Temporal aggregation — first establish Work occurrences and temporal parts under A.15.1, or the identities and temporal relations of other subjects under their own rules. B.1.4 combines those recovered relations for a stated window and use.
• Work-resource aggregation — use B.1.6 for resource spend and yields tied to admitted Work, with the required measurements, accounting boundary and aggregation policy.

Normative guard: Select the rule for the actual composition claim. For domain “process” or “behaviour”, recover the object and predicate under its direct rule; it may concern a Method, Work, A.3.4 transformation, A.6.F functional behaviour, mechanism, or another domain object. Add an explicit distinction only when the intended value is not cheaply recoverable.

A.7:5.8 - 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 independently constituted Description episteme and requires checkable claims plus a named harness, validation, conformance, measurement, or evaluation relation capable of checking them for the stated use. Formality, acceptance, a C.16 measurement criterion, or verification practice may contribute to that test but does not substitute for it. When viewpoint selection affects reliance, preserve or explicitly update the named describing use and its exact selected viewpoint. 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. That availability relation alone identifies neither the EntityOfConcern nor the Description episteme and grants no specification use or evidence use. A description may independently concern one of these publication objects. Name A.10 carrier/source-currentness relations when the receiving evidence, source, or reliance use depends on them.
• Publication-face field pins. A TechCard retains the source pins needed to interpret its claims. For a displayed numeric or comparable characteristic value, resolve the characteristic and its interpretation rule; the CHR-Pins fields are {UnitType, ScaleKind, ReferencePlane, EditionId}, with each supplied when it affects that interpretation. An E.17 publication profile is separately selected. A nonnumeric description requires no unit or scale merely from being shown as TechCard.
• 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.

A.7:5.8a - 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:

When a sameness, difference, or reuse claim needs mathematical justification, use the defining mathematical rule; use C.29 only for an actual lens. E.18 and E.18.1 govern their transformation-flow and problem-to-work carry-through claims, and E.18 applies when a gate crossing is the live relation. A structural, graph, flow, or architecture-description comparison uses its relevant architecture pattern. If no rule supplies the needed identity, correspondence, or postulate-theory justification, leave that claim unresolved.

A.7:5.8b - 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.

A.7:5.9 - 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 when its C.2.1 constitution, checkable claims, and a named harness, validation, conformance, measurement, or evaluation relation capable of checking them for the stated use are recoverable under E.10.D2 and the applicable direct pattern. When viewpoint selection affects reliance, preserve or explicitly update the named describing use and its selected viewpoint. Formality, acceptance conditions, measurement criteria, and verification practice contribute under their own rules; formal notation alone is insufficient. Specification use remains separate from the EntityOfConcern, Description identity, publication expression, and Work.

A Description episteme, its specification-use status, and a publication result are distinct from the dated activity that produces them. An actual describing, formalizing, specifying, or publishing activity may be admitted separately as Work. Use B.1.5 for Method composition, A.15.1 for Work occurrences and temporal parts, B.1.4 for aggregation of already established temporal relations, and B.1.6 for resource spend and yields tied to that Work. An ordinary statement about authoring needs those relations only when its claim uses them.

A.7:5.10 - 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.