#Cluster A.V - Constitutional Principles of the Kernel

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

#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

#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. Role vs Function (mask 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 (role values and role-assignment relations), A.3.4 (transformation), A.10 (evidence-provenance and carrier/source-currentness relations), A.14 (Advanced Mereology), A.15 (Role-Method-Work Alignment), C.2.1 (U.EpistemeSlotRelation), E.17 (publication and view discipline), and F.9, F.17, and F.18 bridge and naming discipline.

#Problem frame

• Holons (A.1) and systems. All holons are part-whole units; systems or acting holons enact behaviour through work-facing role assignments in a bounded context.
• Transformation (A.3.4) and role assignment (A.2/A.2.1). Every claimed change names the transformation or work occurrence, the affected entity, and any current U.RoleAssignment for the acting system or holon; there is no “self-magic”.
• Method/work backbone (A.3.1, A.3.2, A.15). We separate MethodDescription (description), Method (abstract way-of-doing), Capability (a system's ability or envelope to enact a Method under conditions), WorkPlan (intent window), and Work (run-time occurrence), with the acting side expressed through U.RoleAssignment when a work-facing role is current.
• 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 returns the work to the subject pattern. 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. • Typed describing morphism and specification-use boundary — Describe_EoC_DescEp : EntityOfConcern -> DescriptionEpisteme describes an EntityOfConcern value into a Description episteme under a declared construction/reference trace; it is not a mechanism and does not execute work. A later refinement, formalisation, or specification-use claim over that Description episteme is governed by the neighboring pattern governing the claim whose force is live: A.6.2 for effect-free episteme refinement, C.2.3 for formality and checkability, A.21 or the relevant gate/acceptance pattern for harness and acceptance force, C.16 for measurement criteria, E.17 for publication expression, and E.10 for suffix discipline. A.7 keeps those boundaries visible but does not turn them into a second strict-distinction member. Laws (normative for A.7): (DESC-1) Non-extensibility of content and (DESC-2) identity and meaning-preserving composition. Specification-use/refinement laws are enforced by the neighboring pattern governing the claim that selects the gate and value set.

• EntityOfConcern / episteme / publication boundary — EntityOfConcern wording names the item under concern under the declared construction/reference trace; it does not name a document, publication face, carrier, or unspecified referent. Describe_EoC_DescEp yields a Description-side U.Episteme about that EntityOfConcern value. A Description episteme may later be used as a specification only when a bounded use declares formality plus checkable constraint, harness, acceptance condition, C.16 measurement criterion, verification use, or another specification-granting gate. Publication faces, cards, views, publication relation positions, records, and carriers remain orthogonal relation positions: they can make Description epistemes available, but they do not become the EntityOfConcern value, the Description episteme, specification-use gate/refinement, evidence, gate passage, work, assurance, or decision force by appearing in a publication form.

A.7 establishes the following pairs and triplets. Use their names and scope exactly as below.

#Role vs function-like wording, functional behaviour, capability, method, and work

• Role (role value). A context-bound work-facing role value assigned through U.RoleAssignment (A.2, A.2.1, A.15). A role value is not behaviour; it names the assigned work-facing position under which an acting system or holon may enact behaviour. Example: CoolingCirculatorRole@Context in a thermal loop.
• 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 role assignment. A system or acting holon under a current U.RoleAssignment may have a Capability to enact a Method under conditions and may perform Work that produces, maintains, prevents, or checks a transformation/effect. The role is not the behaviour, Method is not identical to transformation/effect, and Capability is not the Method.

Safe rewrite for earlier "Holonic Duality (Substance vs Function)": Holonic Duality (Substance vs Role). A U.System keeps its identity while changing assigned role values; each assigned role value may require a Method, a Capability envelope to enact that Method under conditions, and possible Work occurrences.

Normative guard: Use Role for the role value, U.RoleAssignment for the assignment relation, functional behaviour when A.6.F governs the behaviour claim, Method for the abstract way-of-doing, Capability for a system ability/envelope to enact a Method under conditions, Work for the performed occurrence, and Transformation or effect wording when A.3.4 governs the change claim. Do not call the role itself a function, and do not define Method as Capability or as the transformation/effect itself.

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

• MethodDescription — the description (algorithm / SOP / recipe / script) at design-time. 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 and not the system ability itself; concrete values are bound at U.Work creation. Outside executions we refer to it via MethodDescription (see A.3.1 CC‑A3.1‑5/‑9; A.15 §2.2, §4.1).
• Capability — the system ability/envelope to enact a Method under stated roles, conditions, resources, and constraints. A Capability belongs to a system-in-context; 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).

Normative guard: Never use MethodDescription as evidence of Work; never present Method or Capability as if it had happened; never define Method as Capability.

#Holon vs System vs Episteme (who can act)

• System or acting holon — the entity that can enact behaviour when it is the holder of a current work-facing U.RoleAssignment.
• Episteme — cannot act and does not hold work-facing roles; it is changed via carriers, publications, and work on those carriers by systems or acting holons. Reference, constraint-source, evidence, status, source, requirement, publication, and assurance uses are direct relation/use cases, not episteme roles.
• Holon — umbrella term; do not use it where the current claim requires a system as role-assignment holder. Write the exact holder and U.RoleAssignment(holderRef, roleRef, boundedContextRef) when a work-facing role such as TransformerRole@Context is current.

Normative guard: Work-facing roles, including TransformerRole@Context when used, are role values in U.RoleAssignment and have a system or acting holon as holder in a bounded context. Epistemes do not hold roles merely because they are used as references, evidence, constraints, sources, requirements, publications, or assurance inputs.

#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).

#Collective vs Set, and MemberOf vs Component/Constituent/Portion/Phase (A.14)

• Set / Collection (MemberOf) — mathematical or catalog grouping; no joint behaviour implied.

• Collective System — a system with boundary and coordination Method (e.g., a team).

• Use relations correctly:

  • ComponentOf — mechanical/structural part in systems.
  • ConstituentOf — logical/content part in epistemes.
  • PortionOf — quantitative portion with conserved extensives.
  • PhaseOf — temporal part/state across a continuous identity.
  • RoleAssignment — a system or acting holon is the holder in a current U.RoleAssignment.

Normative guard: If the grouping is expected to act, model a collective system (not a set) and provide its role, Method, and Work.

#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)

• A.7 and E.10.D2 govern the EntityOfConcern-to-description boundary. What the EntityOfConcern value is and how it is described are distinct questions. Description is a U.Episteme use with DescriptionContext. Specification is a gated use or refinement of a Description episteme, selected by checkability, formality plus checkable constraint, harness, acceptance, C.16 measurement criterion, verification use, or other neighboring pattern governing the claim force; it is not a peer class beside EntityOfConcern and Description.
• 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}.
• Bridge policy. Cross-context or cross-reference-plane reuse cites Bridge id + CL; Phi(CL) and Phi_plane penalties apply to R (trust) only; F and G invariant.

#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 direct governing 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.

#Typed describing morphism and specification-use boundary (normative)

What Describe_EoC_DescEp means in A.7. For any EntityOfConcern value X, describing X is the morphism application Describe_EoC_DescEp(X) : DescriptionEpisteme. A.7 does not define a second strict-distinction arrow from Description to Specification. When a Description episteme is formalised, constrained, test-harnessed, accepted, or used as a specification, that is an episteme-refinement or specification-use question handled by A.6.2, C.2.3, A.21, C.16, E.17, E.10, or another neighboring pattern governing the claim according to the live force.

Example. A formal postulate theorem in physics can be a Description episteme about the behaviour of a physical grounding holon. Its formal language belongs to formality and publication-expression discipline. It becomes a specification only if a bounded use assigns specification force, such as acceptance criteria, harness checks, normative invariants, or verification use. Formal notation alone does not make it a third kind beside the physical EntityOfConcern and the Description episteme.

Invariants (normative for A.7, split by EntityOfConcern kind):

1. Episteme-source preservation (DESC-1E). When the EntityOfConcern value X is itself a U.Episteme, a claim graph, a claim-bearing view, or another claim-bearing source, Describe_EoC_DescEp(X) MUST NOT silently add epistemic commitments. Added structure is only declared representation, indexing, cross-reference, or refinement/loss under the neighboring pattern governing the claim that grants it.
2. Non-episteme describing trace (DESC-1N). When X is a system, structure, work occurrence, role assignment, method, physical object, characteristic, relation, or other non-episteme value, claims are not "inside X" waiting to be copied. A Description episteme may add claims about X only through a declared construction, reference, measurement, observation, model, postulate-theory, or witness trace, with admissibility conditions visible for the intended use.
3. Identity and meaning preservation (DESC-2). If f : X -> Y is a meaning-preserving, bridge-admitted, or construction-preserving map for the selected EntityOfConcern values, then Describe_EoC_DescEp(f) is defined only for the declared scope and preserves the identity, near-identity, bridge, loss, or retargeting relation that the governing pattern admits. Where meaningful composition exists, Describe_EoC_DescEp(f o g) = Describe_EoC_DescEp(f) o Describe_EoC_DescEp(g) only under that declared relation.
4. Specification-use refinement case. If a Description episteme is refined into specification use, the refinement must name the neighboring pattern governing the claim and gate that grants that use. A.7 only requires that the refinement remains separate from the EntityOfConcern, from publication expression, and from Work.
5. Separation from Gamma. Describe_EoC_DescEp and any neighbouring specification-use refinement do not compose with Gamma_method, Gamma_time, or Gamma_work; describing, formalising, or specifying is not execution and accrues no resource or time semantics.
6. Ontology preservation. Describing any EntityOfConcern value, such as a Calculus, Signature, Mechanism, Structure, Work occurrence, or Episteme, via Describe_EoC_DescEp does not change its ontology; it yields a Description episteme under A.7 rules. Publication through faces, forms, units, and carriers is handled separately in E.17 (MVPK).

#Bridge to U.Work (normative invariants)

OUTSPEC‑INV‑1 (No metonymy). promisedOutcomeSpecRef points to an OutcomeSpec, not to U.Work and not to an extensional delivered-result referent. The actuals live on U.Work (A.15.1) and its evidence carriers.

OUTSPEC‑INV‑2 (Evaluability from work evidence). All predicates referenced by workPredicateRef, postConditionRef, and unitOfDelivery.countingRule.* MUST be evaluable from U.Work facts and cited evidence (including U.Work.Δ state records or evidence carriers). They MUST NOT require introspecting the internal structure of the provider system unless that structure is itself exposed as evidence.

OUTSPEC‑INV‑3 (Counting coherence). If unitOfDelivery is present, its countingRule MUST select only work episodes that are eligible to satisfy the promise content and MUST not silently double‑count (use dedupeKeyRef or a cited policy).

#Canonical examples (didactic)

Example 1 — Work‑only (promise the work): “provide consultation for ≥5 minutes”.

OutcomeSpec(OS‑Consult‑5min) := {
  mode: WorkOnly,
  workSpec: {
    methodConstraintRef?: MD‑Consultation,
    workPredicateRef: E‑(duration(work) ≥ 5 minutes)
  }
}

unitOfDelivery := {
  unitLabel: "minute",
  countingRule: {
    selectorRef: E‑(work fulfils OS‑Consult‑5min),
    quantityRef: E‑durationMinutes(work),
    aggregation: sum
  }
}

Example 2 — Result‑only (promise the world state): “a hole of depth ≥ 1 m exists”.

OutcomeSpec(OS‑Hole‑1m) := {
  mode: ResultOnly,
  resultSpec: {
    deliveredResultReferentRef: kind(Hole),
    statePlaneRef: GeometryPlane,
    postConditionRef: E‑(depth(hole) ≥ 1 m ∧ location(hole) within SiteScope)
  }
}

unitOfDelivery := {
  unitLabel: "hole",
  countingRule: {
    selectorRef: E‑(work fulfils OS‑Hole‑1m),
    quantityRef: E‑1,
    aggregation: count,
    dedupeKeyRef: E‑holeId(work)         // prevents double counting when rework happens
  }
}

Example 3 — Composite (promise both): “hairstyle for the evening, produced within 20 minutes, by cut+style (not a wig)”.

OutcomeSpec(OS‑Hair‑Evening‑20min) := {
  mode: Composite,
  workSpec: {
    methodConstraintRef: MD‑CutAndStyle‑NoWig,
    workPredicateRef: E‑(duration(work) ≤ 20 minutes)
  },
  resultSpec: {
    deliveredResultReferentRef: kind(HairstyleOnClient),
    statePlaneRef: AppearancePlane,
    postConditionRef: E‑(looksLike(style="Evening") ∧ survivability(afterShower) ≥ acceptable)
  }
}

unitOfDelivery := {
  unitLabel: "session",
  countingRule: {
    selectorRef: E‑(work fulfils OS‑Hair‑Evening‑20min),
    quantityRef: E‑1,
    aggregation: count,
    dedupeKeyRef: E‑appointmentId(work)
  }
}

(Where E‑(…) denotes an Episteme/predicate defined in the relevant Context; this appendix does not introduce an expression language.)

#Archetypal Grounding (Tell-Show-Show; System and Episteme)

#System and Episteme example

System archetype — “Digital‑twin vs asset”. Claim: The twin (episteme) does not “act”; the system or acting holon under a current U.RoleAssignment enacts Work on the asset; evidence binds through A.10 carrier/source-currentness and evidence-provenance relations. Show: A maintenance MethodDescription (tech card) lives at design‑time; a Work record (assurance face) lists Γ_time, Γ_work, PathId and carrier ids for telemetry. The twin’s update is Work on the carrier, not the asset; CL^plane penalties are disclosed when twin–asset crossings are analysed.

Episteme archetype — “Peer‑review vs manuscript”. Claim: A review is Work by a system (the reviewer) on carriers of an episteme (the manuscript). Show: The MethodDescription is the review SOP; the Work cites carrier ids (file/edition) and the selected episteme; arguments/rebuttals live on epistemes; acceptance gating lives in CAL, not in CHR cards.

#Didactic examples

Example 1 — Pump in a cooling loop

• Substance (system): Centrifugal pump P‑12.
• Role: Cooling‑CirculatorRole.
• MethodDescription: “Loop Circulation v3” (TechCard, cited through A.10 carrier/source-currentness refs when evidence or source use is current).
• Method: ordered way-of-doing: start → ramp → hold → stop (Γ_method).
• Capability: P-12 control-unit ability/envelope to enact that Method under stated roles, conditions, resources, and constraints.
• Work: run on 2025‑08‑09 10:00–10:45; energy ledger via Γ_work; log via Γ_time.
• Safe phrasing: “The system playing Cooling‑CirculatorRole (via the P‑12 control unit as Transformer) had the Capability to enact the Method described by MethodDescription, and executed Work …”
• What not to write: “The pump’s function is the role” (role ≠ behaviour).

Example 2 — Standard document cited in a design

• Episteme: “Safety Standard S‑174”.
• Carriers: PDF and printed volume with A.10 carrier/source-currentness refs when the standard is used as source or evidence.
• Use relation: reference-use or constraint-source-use relation for the valve selection activity, named by its direct governing pattern.
• Role assignment for work: U.RoleAssignment(holderRef=DesignTeamSelectionSystem, roleRef=TransformerRole@ValveSelectionContext, boundedContextRef=ValveSelectionContext) when the selection work needs a work-facing transformer role value.
• MethodDescription: “Valve Selection SOP v5”.
• Method: abstract valve-selection way-of-doing described by that SOP.
• Capability: design team's selection-service ability/envelope to enact the Method under the project conditions.
• Work: dated selection session that used the standard; the episteme did not act.

Example 3 — Set vs team

• Set (MemberOf): {Alice, Bob, 3.14} — a collection; no behaviour implied.
• Collective system (team): boundary, coordination Method, supervision Work; can hold a current U.RoleAssignment for a work-facing role value such as CoolingMaintenanceRole@Context.
• Safe phrasing: “U.RoleAssignment(holderRef=TeamT, roleRef=CoolingMaintenanceRole@Context, boundedContextRef=ContextT) is current for Work W…”

#Conformance Checklist (normative)

#Canonical rewrites (didactic library)

#Anti‑patterns (with fixes)

1. Role‑as‑behaviour — calling the role “the function”. Fix: Name the role, Method, and Work explicitly.

2. Episteme‑as‑system — “the model routed traffic”. Fix: Name the system or acting holon, its U.RoleAssignment when a work-facing role is current, the Work that used the model, and the carriers touched.

3. Triad everywhere — omitting Work entirely. Fix: Add the Work position: timestamps, outcomes, Γ_time coverage.

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

5. Set‑as‑collective — a MemberOf set “decides”. Fix: Model a collective system with coordination Method.

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 role swap in tables — columns labelled “Function” but entries are roles. Fix: Rename column to Role; 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: Separate describing (Describe_EoC_DescEp), specification-use refinement, and publication (MVPK Description-episteme-to-publication face, form, unit, carrier, and rendering availability). If there is operational toil (build, render, upload), model it as Work by a system on carriers; do not change the EntityOfConcern value, the Description episteme, specification-use gate/refinement, or the publication relation being presented.

#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 specifications as descriptions, procedures as capabilities, and operations as occurrences mirrors established systems-engineering discipline while keeping FPF’s holonic rigor.
• Didactic primacy: Practitioners can approve sentences by spotting the work-facing chain in context: acting system or holon, U.RoleAssignment, MethodDescription, Method, Capability, WorkPlan, Work, and A.10 evidence-provenance or carrier/source-currentness relation where evidence is claimed.
• 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 (role values and role-assignment relations), A.3.1/A.3.2/A.3.4 (Method, MethodDescription, Transformation), A.10 (evidence-provenance and carrier/source-currentness relations), A.14 (Advanced Mereology), A.15/A.15.1/A.15.2 (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 (Authoring conventions), E.10 (lexical and precision restoration), Part F and Part G (UTS and CG-Spec or CHR pinning), B.3 (assurance-use discipline), C-cluster (selection and archives) by enforcing EntityOfConcern and Description-episteme boundary, specification-use boundary, publication availability orthogonality, System and Episteme separation, same or near-same EoC discipline across views, and typed EntityOfConcern-to-Description describing discipline (publication = Description-episteme-to-publication face, form, unit, carrier, and rendering availability in E.17).
• Coordinates with: E.18 (gate crossing and OperationalGate(profile)) for crossing visibility and publication gating, A.21 for gate checks, F.9, F.17, E.17, and E.18 for Bridge+UTS pinning discipline, E.10 for lexical SD checks, and Part F (Bridges and CL) for explicit cross-Context identity, without embedding any notation dependence.

#Practitioner one-page review (copy-paste)

Approval sentence template

“U.RoleAssignment(holderRef=⟨system-or-acting-holon⟩, roleRef=⟨Role@Context⟩, boundedContextRef=⟨Context⟩) is current for the work; the holder has Capability ⟨C⟩ to enact Method ⟨M⟩ (from MethodDescription ⟨S⟩), executed Work ⟨W⟩ on ⟨time⟩, and cites A.10 evidence-provenance or carrier/source-currentness refs ⟨ids⟩; resources are accounted through the governing work-cost relation.”

Five binary checks

1. Bare acting-subject check: No bare “actor” token in normative core claims; canonical U.RoleAssignment phrasing is present when a work-facing role is current.
2. Clear quartet: MethodDescription, Method, Capability, and Work are all named (as applicable) and not conflated.
3. Right Γ: Γ_method composes Method; Capability states a system ability/envelope under conditions; Γ_time covers occurrences; Γ_work accounts resources; Γ_sys covers system properties.
4. Episteme handled: Epistemes do not act; carriers or source-currentness refs are listed when evidence or source use is current.
5. Group clarity: Acting group is a collective system, not a MemberOf set.

Diagram legend stub

• “process (domain)” ⇒ Method (design‑time) / Work (run‑time).
• Role column lists role values and assignment references (e.g., CoolingCirculatorRole@Context).
• Behaviour column shows Method and Work, not the role itself.

#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 direct-owner 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, return to the domain or evidence owner. 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, exit to 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; a named admitted U.System under the current engineering or analysis role assignment performs the dated ontology-analysis U.Work. The reader, performer, method episteme, 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 name the right role word while ignoring whether an assignment relation ever began. 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, direct-owner return, 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, role, state, capability, relation, 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

#Inherit the complete application contract

This A.7.1 description 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, separation among method, reader, performer, Work, and result, positive stop, and reopen rule. This is description-level claim reuse; it 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 and that subject's current direct owner; subject and owner 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, A.15.2 owns planning and A.15.1 owns dated work; 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, direct-owner 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 relation, role, state, capability, method, work, and evidence owners 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, role-assignment, holon-recognition, work-occurrence, state/capability, or structural-construction owner. 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 owners.
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, send the candidate to its admission owner and return after admission.

#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 direct-owner distinction. Reopen only the affected engineering and ontology decisions.

A short domain/wording/typed-account/constructive-ground presentation may be kept as a ProvisionalUnfoldingDemonstrationDescription@Context. It is a teaching episteme, not an admitted CGUS, method, plan, work occurrence, or result. A reusable structure requires the full A.22.CGUS admission coordinates.

#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 owner constrains the disputed claim; neither the bearing/shaft subject nor that owner 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” for both MemberOf and ComponentOf. Removal action differs only in the structural construction case. The work returns the disputed item to C.13, repairs the direct maintenance claim, and leaves unrelated set membership 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 direct owners 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, direct-owner return, 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 direct-owner 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 direct owner remain inputs and constraints. A.7.1 retains the declared use, problem-facing result, claimed guarantee, horizon, useful threshold, separation among reader, performer, Work, and result, stop, and reopen. 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 premise owner.
• Returns to: direct relation, role, holon, state, capability, method, work, evidence, temporal, structural, and domain owners 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 or formal owners for missing warrant, and source-currentness owners 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; an admitted U.System performs dated reconciliation U.Work under a distinct current U.RoleAssignment for an FPF author or maintainer role. The pattern episteme, reader, performing system, assignment, work, source uses, and returned FPF decision remain distinct.

#Problem frame

Neighboring FPF pattern and method epistemes can state different premises about existence, constitution, identity, dependence, obtaining, representation, agency, or formal projection. A dated application of a role-method clause may yield a decision claim that assignment work or a policy-valid instituting act must occur before responsibility 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 select different responsible systems 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 receiving claim, which direct owners decide evidence and currentness, 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 owners. 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 direct-owner decisions, and repair the method clause or direct-owner 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 owner 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 exact source episteme and edition consumed. The receiving participant is the exact ontology-claim episteme and edition being formulated, constrained, tested, interpreted, compared, or traced. The work participant is the dated ontology-decision U.Work: its already admitted holder U.System performs that work under an exact current U.RoleAssignment. When an F.6 performedBy(W, RA) attribution is cited, RA.HolderSystemSlot must resolve to that same system; the assignment neither supplies the system nor performs the work.

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 direct owner. 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 owners. 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 or decision owner 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 application of a role-method clause yields a decision claim that assignment work or a policy-valid instituting act constitutes a responsibility-bearing U.RoleAssignment. Another dated application of a neighboring relation-method clause yields a claim that a signed organization chart is sufficient to make the same assignment occurrence obtain. The two result claims select different responsible systems for one maintenance action. 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 relation clause so the chart is evidence for an assignment assertion rather than constitution of the assignment, then checks the affected application result. The result is reconciledCompatibility; unrelated evidence and publication law stays unchanged.

Context split. One dated application uses a pattern's ComponentOf clause to classify a pump assembly; another uses a MemberOf clause to classify a maintenance-candidate set. 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 or decision owner, 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 owners, 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 direct-owner 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 and method epistemes supply clauses or declared premises, while dated application work and its 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 method episteme does not perform work”. A method episteme may separately state or cite one of those claims as a declared premise or branch condition under its own episteme/declaration owner. 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 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 method description can declare an intrinsic premise or a branch condition under its own episteme/declaration owner; 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 owner 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 method episteme describes a way of working; an admitted system under a role assignment performs dated work and produces results.
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 remains the owner of constructional mereology only.
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 Direct-owner separation. Capability, state, architecture, role, method, work, evidence, permission, and relation families retain their direct owners 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:
  basisClaimIdRef: ClaimIdRef
  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 and exact compact claim ID used. ReasoningWorkSlot is the dated reasoning, choice, ontology-analysis, or reconciliation U.Work that relies on it. ReceivingReasoningResultSlot is the exact 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 exact governed result claim that bears on it; the world-side object retains its direct owner. The already admitted holder U.System performs the work under an exact current U.RoleAssignment; when F.6 performedBy(W, RA) attribution is cited, RA.HolderSystemSlot must resolve to that same system. The assignment neither supplies the system nor performs the work. Claim episteme, work occurrence, 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 owners.

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 direct owners.
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 direct owners.

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 owner, 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 stable content ownership 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 direct-owner 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 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 method epistemes may separately declare premises or branch conditions under their exact episteme/declaration owner; neither method description is made 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 direct ownership 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:
  E24UKDecisionRef:
  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 subject-pattern governed.

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, A.11 parsimony, or direct pattern ownership. A failed test is still useful: it tells the project where to keep the candidate local, dependent, or subject-pattern governed. 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 claim, metric, model result, dashboard tile, confidence badge, review note, credential, provenance label, quantum-like statement, causal-use statement, or generated explanation starts acting as evidence while the evidence carrier, evidence-producing work, method trace, time window, source-currentness relation, or rival explanation is still implicit.

Primary EntityOfConcern. The EntityOfConcern is the claim-bound evidence-provenance graph relation: the path in the evidence-provenance graph that links one named claim or effect to concrete carriers, evidence-producing or evidence-interpreting work occurrences, role assignment when current, method trace or work trace, time stance, and admissible evidence use.

First useful move. Write the smallest because-graph that can answer: which claim or effect, which carriers, which evidence-producing or evidence-interpreting work occurrence and role assignment when current, which method or work trace, which time window, which evidence relation, and which bounded use?

What goes wrong if missed. Claims become weightless, dashboards become authority, provenance becomes truth, credentials become permission, generated explanations become evidence, method descriptions get mixed with work traces, and part-whole structure is mistaken for evidence.

What this buys. One bounded evidence relation that can be replayed, contested, refreshed, narrowed, or used by a neighboring governing pattern without making evidence pretend to be approval, permission, gate passage, performed work, assurance, causal authority, or part-whole structure.

Ordinary use. For routine source-finding, orientation, bounded reversible probes, and low-stakes evidence use, keep the evidence relation small: claim, carrier, producer or source-maintenance role assignment, method trace or work trace when relevant, time window, bounded evidence use, unsupported attempted use, and reopen trigger.

Reliance-facing use. Expand the evidence relation only when consequence severity, reuse, contestability, cross-context movement, source-currentness risk, credential reliance, provenance reliance, gate use, release use, assurance use, work use, causal-use claim, or privacy boundary makes the extra field decide the current claim.

Not this pattern when. Not this pattern when the current claim is authorization, commitment, performed work, gate decision, assurance, causal identification, measurement construction, representation-scheme transition, explanation faithfulness, or source publication use itself. In those cases, use the neighboring governing pattern and let A.10 supply only the evidence-provenance graph relation it needs.

Use A.2.4 first when the immediate question is only whether an episteme is being used as evidence or status for a claim, before a full evidence-provenance graph relation is needed. A.2.4 keeps episteme evidence-use and status-use relation slots distinct from U.RoleAssignment; A.10 then owns the full claim-bound evidence-provenance graph relation when the carrier, producer, method trace, work trace, time window, and provenance relation must be replayable.

Here path means a path in the evidence-provenance graph, not a route for actions to follow.

#Problem

Without a uniform evidence-provenance path, models drift into five failure modes:

1. Weightless claims. Metrics or arguments appear in the model with no link to their symbol carriers (files, datasets, lab notebooks, figures).
2. Collapsed scopes. Design-time method specs are silently mixed with run-time traces; results cannot be reproduced because "what was planned" and "what work occurred" are conflated.
3. Self-justifying loops. A claim is used as evidence for itself, or the same work occurrence both produces the target claim and supplies its evidence without a separated evidence-producing or interpreting work occurrence, provenance relation, source-maintenance role assignment, or relying context.
4. Source loss during aggregation. As Γ combines parts, some sources fall out; subsequent audit cannot reconstruct why a compound claim was accepted.
5. Temporal ambiguity. Time-series are aggregated without interval coverage or dating source; gaps and overlaps invalidate comparisons and trend claims.

The business effect is predictable: confidence badges cannot be defended, cross‑scale consistency (A.9) is broken, and iteration slows because every review re‑litigates “where did this come from?”.

#Forces

#Solution — The Evidence Graph Referring Standard

The Standard is a small set of primitives applied uniformly, with practitioner-first clarity and formal connection points for proof obligations. Its primary EntityOfConcern is the evidence-provenance path for a claim or use: an evidence episteme or evidence record, target claim or target use, publication or carrier relation, provenance relation, evidence-producing or evidence-interpreting work occurrence, producer or source-maintenance role assignment when current, method trace when relevant, time stance, scope, polarity, relevance window, and assurance use. Authority-looking reliance and causal-use evidence are specialized uses of that same evidence-provenance path; they do not redefine A.10 as a pattern about labels, dashboard wording, or source rhetoric.

#Evidence-provenance graph relation

A typed, acyclic evidence-provenance graph relation stays disjoint from mereology. Its nodes and references are typed by their current FPF kind: claim or target use, evidence episteme or evidence record, publication or carrier reference, provenance relation, evidence-producing or evidence-interpreting U.Work, U.RoleAssignment for producer, interpreter, verifier, or source-maintenance holder when that assignment is current, U.MethodDescription or method trace when the evidence depends on method, observation or evaluation record, and relevance window. Edge vocabulary is small and normative: evidences, derivedFrom, measuredBy, interpretedBy, usedCarrier, producedByWork, maintainedByRoleAssignment, happenedBefore (temporal), etc. Practitioner view: it is the “because-graph”: every claim answers “because of these evidence items and carriers, produced or interpreted by this work under this assignment, using that method where relevant, within this time window.”

#Evidence relations (two relations, two flavours)

• verifiedBy — links a claim to formal evidence (proof obligations, static guarantees, model‑checking records).
• validatedBy — links a claim to empirical evidence (tests, measurements, trials, observations). Both evidence relations terminate in the evidence-provenance graph relation, not in the mereology graph.

#Evidence-provenance entries with carrier identity and currentness fields

When an episteme composition, publication, compilation, dashboard, generated explanation, or assurance use substantively relies on a carrier-backed source episteme publication, evidence carrier, dashboard row, generated explanation, or assurance record, the evidence-provenance path SHALL keep an evidence-provenance entry with carrier identity fields and source-currentness relation fields: carrier ref, source U.Episteme ref or source U.EpistemePublication ref when a source publication carries the claim, evidence episteme ref or evidence record ref when the evidence is project-side, carrier kind, version or edition when relevant, date or relevance window, source-currentness relation or currentness window, provenance relation, and optional part-carrier relation for sub-carriers. When a bounded context needs publication-grade reuse, the record is adapted to that context with vocabulary, unit, identifier, and hash discipline while preserving carrier identity and carrier integrity. Why this matters: it prevents “lost sources” during composition and underwrites reproducibility without mandating any specific tool or preserving one older register name as the governing ontology.

#Scope alignment across Role-Method-Work

• Design-time: MethodDescription is the design-time episteme describing U.Method; evidence relations reference what would constitute proof or test for that method.
• Run-time: dated U.Work occurrences belong here; traces reference which U.Method they enact and cite the methodDescriptionRef used to identify or constrain it and record happenedBefore. Bridging edges are explicit (“this run trace enacts that method under this method-description source”), so scopes never silently mix.

#Evidence-producing work and relying context

The work occurrence that produces, measures, interprets, verifies, publishes, or maintains evidence is modelled separately from the target claim or target use that relies on that evidence. If the same system participates on both sides, the evidence-provenance path must still name the distinct work occurrence, role assignment, carrier/provenance relation, relying context, and reopen condition. Reflexive monitoring is admissible only when those relations are explicit; it is not evidence by self-label.

#Gamma-flavour evidence connection points

• Γ_sys (formerly Γ_core): physical properties are evidenced by measurement models, boundary conditions, calibration carriers, and dated observations.
• Episteme composition and publication use: every evidence-provenance node resolves to an evidence-provenance entry with carrier identity and source-currentness fields or to an explicitly named evidence episteme, provenance relation, or source-maintenance relation.
• Γ_method: order-sensitive composition; at design-time a Method Instantiation Card (MIC) states Precedes, Choice, Join, and guards; at run-time traces record happenedBefore and point to the U.Method they enact and the methodDescriptionRef they used.
• Γ_time: temporal claims state interval coverage; Monotone Coverage with no unexplained gaps and no unexplained overlaps is required.
• Γ_work: resource spending and yield are evidenced by instrumented carriers (meters, logs) and their methodRef plus methodDescriptionRef; keep resource rosters separate from evidence-provenance entries used for carrier identity or source-currentness.

Practitioner shortcut: If you can answer what carriers, which system, which method, when, the evidence relation is likely sufficient; if any of the four is missing, it is not.

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

Use this subsection when an authority-looking case is being used as evidence for a reliance claim. The A.10 evidence-provenance path is claim-bound: it evidences one named claim or effect for one named work occurrence or reliance use, not "authority" in general. This subsection does not change the A.10 EntityOfConcern; it applies the same evidence-provenance graph relation to source-sensitive cases where displays, credentials, copied text, generated text, dashboards, provenance labels, or attestations are being overread. If the work occurrence, gate decision, speech act, commitment, or evidence relation is already recorded in a project-side FPF source, recover and cite that source named by value directly instead of analyzing nearby wording first.

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 issuer or source-maintenance role assignment, method trace or work trace, time window, and relying context.

Data-minimization and privacy boundary. Preserve minimum sufficient evidence relation for the intended reliance use. Use redacted, hashed, scoped, or role-mediated carrier refs when raw evidence would expose personal identity, access tokens, cryptographic proof payloads, tenant identifiers, security logs, incident details, internal release metadata, audit trails, privileged review-role names, sensitive model provenance, or sensitive data provenance. Redaction does not create source relation; it must preserve enough recoverability for the relying context.

Case repairs:

If the evidence-provenance path is incomplete, A.10 reports evidence-provenance completeness state and source-currentness status, not work or reliance evidence relation for the attempted claim or effect. Possible dispositions include source-finding only, reopen original carrier, request issuer or status verification, refresh dashboard query or API 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 when a work change is being attempted, or block the unsupported work claim or reliance claim.

Missing source-relation repair assignment. If the relying actor cannot recover or verify the source relation, assign the repair to the accountable project-side responsibility assignment: issuer or performer, verifier assignment, status-source relation, evidence-producing work assignment or evidence-producing system, gate-decision source relation, role-assignment source relation, status register entry, boundary claim relation, or source-currentness relation. The A.10 result should name the missing source relation or missing 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, source-maintenance role assignment, 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 relation 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, source-maintenance role assignment, method trace, work trace, and time relation needed, rival explanation that made the overread plausible, current safe disposition, and upstream repair action for instrumentation, source U.EpistemePublication refs, source relation refs, status, currentness, claim-bound source relations, credential view, model documentation, data documentation, or provenance and 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 should name the disputed claim, evidence carrier, source-maintenance role assignment, verifier assignment, status relation maintainer, freshness relation, revocation relation, privacy-minimized evidence ref, safe interim disposition, and review or redress relation. A disputed display remains contested until the source-order relation or currentness relation is resolved.

Positive repaired evidence-use statement. When the source relation is complete, write the smallest source-backed evidence-use statement: named claim or effect, evidence carrier and source-maintenance role assignment, method trace or work trace, time window, currentness, evidence relation, and the named work use or reliance use for which the evidence relation is bounded. The downstream use stays inside that scope, without treating evidence relation as approval, permission, gate passage, work occurrence, or assurance.

What this does not authorize: A.10 does not approve, authorize work or reliance, pass a gate, release, create permission, create a commitment, assign a role, record a work occurrence, or raise assurance. It supplies the evidence-provenance path and evidence-use classification that A.15, A.6, B.3, A.21 gate-decision source relations, A.20 constraint-validity source relations, A.2.9 speech-act source relations, A.2.8 commitment source relations, A.15.1 work-occurrence source relations, or another governingPatternRef or authoritySourceRef named by value may consume.

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

Use this subsection when a visible carrier, publication face, source U.EpistemePublication ref, source relation ref, or display is being treated as evidence for a claim, act, work occurrence, gate, release, review claim, assurance use, or problem-side P2W use. The first A.10 action is to recover the evidence kind and the bounded evidence use. Broad source words such as source, metric, confidence, conformant, safe, ready, certified, approval, or permission are only recovery prompts; they do not name the evidence relation by themselves.

This subsection uses a local reliance-use classifier, not a Core evidence-kind ontology. Its practical gain is a smaller next action: recover the evidence relation, name the bounded evidence use and unsupported attempted use, then either stay inside A.10 or apply the governing pattern for the stronger claim being made. It is not a required project review step and does not ask the practitioner to inspect every carrier or display that merely appears source-bearing.

Section role: the first table is an A.10 recognition aid, the RelianceDisposition table is a minimum local record aid, and the worked source-overread slices are regression slices and review slices. They are not project checklists, a required sequence, a new evidence ontology, or a general source classifier. Use only the row that answers the attempted evidence use, then stop when the bounded evidence relation, unsupported attempted use, and reopen condition are clear. This local section keeps the attempted use inside the A.10 evidence relation; it does not create an extra SEMIO authority or cross-pattern relation vocabulary.

Affordability card: orientation or source-finding remains a cue and stops here; bounded reliance states one bounded evidence use, unsupported attempted use, window, and reopen condition; threshold reliance applies the minimum governing pattern only when the B.3 material-reliance threshold is met: behavior, safety, release, compliance, public or protocol behavior, access, resource allocation, people status, team status, operational action, or controlled-object regulation would materially change. Plain wording remains ordinary unless it changes bounded use, source relation, evidence, gate, assurance, work, decision, or neighboring governing-pattern claim.

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 assurance claim, gate relation, work relation, control-bearing relation, release relation, or met B.3 material-reliance threshold, 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, source U.EpistemePublication 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 stay with their governing patterns when those relations are being claimed.

Plain disposition palette: RelianceDisposition=pass means proceed only inside the bounded evidence use; RelianceDisposition=degrade means use only a narrower or reversible version; RelianceDisposition=abstain means do not decide yet; RelianceDisposition=reopen means changed or contested evidence relation defeated the previous evidence-use classification; RelianceDisposition=evidence-needed means ask for the named missing evidence at the named decision point; RelianceDisposition=safety-case-required means apply B.3 because the B.3 material-reliance threshold is met; RelianceDisposition=blocked-current-use means block the current attempted use until the evidence-provenance path or governing 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 only when the affected party or accountable review role can identify the disputed claim or source, affected use or harm, accountable review role, evidence or argument allowed in challenge, possible disposition change, outcome record, and reopen trigger. A feedback channel, complaint form, or appeal label without those recoverable values is not enough to change the disposition.

Affected-party contestable minimum: even when raw evidence stays review-role-mediated, the contesting party must be able to see enough of the claim, source class, disposition, affected use, accountable role, 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 source U.EpistemePublication, 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 role-mediated 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:

#Causal evidence relation values in evidence-provenance paths

Evidence graph paths used for causal-use claims must carry the C.28-governed CausalEvidenceSupportBasis value without redefining causal estimands or causal-use authority. In this subsection, SupportBasis is a C.28 field-value name; it is not the loose FPF prose word "support".

The C.28 values that A.10 may carry in an evidence-provenance path are:

observationalAssociationSupportBasis
interventionalActionSupportBasis
realizedCounterfactualSampleSupportBasis
identifiedCounterfactualEstimateSupportBasis
simulationOnlyCounterfactualOutputBasis

[A.10](/generated/patterns/A.10) consumes this value set from [C.28](/generated/patterns/C.28); it does not add causalAssumptionOnlySupport or noCausalEvidenceSupport as causal-evidence values. Assumption-only and no-evidence-use cases are represented by causal assumptions, a [C.28](/generated/patterns/C.28) causal-use verdict, bounded use, unsupported attempted use, or abstain in [C.28](/generated/patterns/C.28)/[B.3](/generated/patterns/B.3), not by a second causal-evidence vocabulary.

No unsupported causal-use shift:

observational-association evidence -> interventional-action claim requires CausalIdentificationProfile.
interventional-action evidence -> counterfactual-comparison claim requires CausalIdentificationProfile for
  identifiedCounterfactualEstimateSupportBasis, CounterfactualSamplingRealizabilityProfile for
  realizedCounterfactualSampleSupportBasis, or bounded-use treatment.
Simulation-only counterfactual output may be used only for the bounded claim stated for that simulator output when model assumptions, validation, bounded use, and unsupported attempted use are declared. It does not become interventional evidence or realized counterfactual sample evidence by vocabulary, validation, or evidence-role relabeling alone.

Evidence-provenance path micro-examples:

What changes in practice: an evidence-provenance path can show that a carrier evidences a causal-use claim, but it must also show the causal evidence relation value and the relevant [C.28](/generated/patterns/C.28) references when the claim changes from observation to intervention or from intervention to counterfactual comparison.

What this does not authorize: [A.10](/generated/patterns/A.10) does not identify causal effects, create an estimand, certify target-trial emulation, or decide counterfactual sampling realizability; it stores and makes recoverable the evidence graph path and the [C.28](/generated/patterns/C.28) causal-evidence refs needed by [C.28](/generated/patterns/C.28) and [B.3](/generated/patterns/B.3).

#Archetypal Grounding

#Bias-Annotation

A.10 corrects evidence-presentation bias: a visible carrier, dashboard tile, credential view, model card, generated explanation, provenance mark, or attestation can look like evidence, approval, permission, assurance, or work authority before the claim-bound evidence relation is actually present. The repair is not to collect more impressive paperwork. Recover the bounded evidence-provenance graph relation for the named claim or effect: carrier or source, evidence-producing or evidence-interpreting work occurrence, role assignment when current, method trace or work trace when relevant, time window, currentness relation, rival explanation, and bounded evidence use.

The second bias is graph-kind drift. A path in the evidence-provenance graph is a mathematical relation inside the evidence description; it is not a route of action, a part-whole edge, a method sequence, a gate passage, or a permission trail. When the current claim is about those neighboring relations, A.10 supplies evidence for them and returns authority to the governing pattern.

#Conformance Checklist

Practitioner’s audit (non‑normative, quick): For any claim, ask What carriers? Which system? Which method? When? If any answer is missing, A.10 is not satisfied.

#Common Anti-Patterns and How to Avoid Them

• Carrier as truth. A cited document, dashboard cell, credential display, generated answer, or provenance label is treated as the claim being true without the evidence relation and currentness window.
• Evidence as permission. A strong evidence-provenance path is overread as authorization, gate passage, commitment, release, or performed work.
• Provenance as part-whole. Provenance edges are used to build holarchies, or part-whole edges are used as evidence.
• Method description as work trace. The method episteme says what would count as good work, but the actual work occurrence, carrier relation, or source relation is absent.
• Self-evidence. The target claim, its display, or its producing work is allowed to evidence itself without a separated evidence-producing or evidence-interpreting work occurrence and relying context.
• Full dossier by default. A source-finding or low-stakes reliance case is expanded into every possible evidence field instead of the minimum field set that decides the current bounded use.

#Consequences

#Rationale

Evidence use becomes reviewable only when the relied-on claim, evidence carrier, source U.EpistemePublication ref or source relation, evidence-producing or evidence-interpreting work, source-currentness relation, time window, rival explanation, and bounded relying context are separate. A.10 therefore makes the evidence relation available to assurance, gate, role, status, work, publication, causal-use, and source-use patterns without letting the evidence relation itself become approval, permission, work occurrence, or truth.

#SoTA-Echoing

• Metrology & assurance. The requirement to name quantities, units, uncertainty, calibration carriers reflects long‑standing metrology practice and modern assurance cases: numbers are only comparable when their measurement models are stated.
• Knowledge provenance. The evidence-provenance graph relation and evidence-provenance entry with carrier identity and source-currentness fields embody post-2015 best practices in provenance for epistemes and their carriers: keep a complete, machine-checkable trail from claims to carriers; separate provenance from part-whole.
• Temporal reasoning. Monotone coverage with no unexplained gaps and no unexplained overlaps aligns with temporal knowledge graph practice and avoids impossible histories.
• Holonic parsimony. By drawing a firewall between mereology (A.14) and provenance, A.10 prevents semantic leakage and keeps the holarchy well‑typed.
• Role–Method–Work clarity. Evidence relationing explicitly rides on A.15: roles act via methods specified at design‑time and produce work observed at run‑time. This keeps agency, policy, and execution disentangled yet connected.
• Credential, provenance, attestation, status-register, and generated-source currentness. Verifiable-credential and digital-identity practice separates issuer or trust root, holder binding, proof result, status result, revocation, effective window, audience, and relying context. Some bounded contexts also treat a register entry or status register entry as the authoritative record or relation that creates or changes role assignment, status assertion, permission, duty, or gate state; a credential view, pass, badge, dashboard cell, API response, screenshot, or certificate excerpt is then a publication of that record or relation, not automatically the governing record or relation itself. C2PA content provenance plus SLSA and in-toto attestations separate bounded origin, history, build, and process claims from truth, approval, release, safety, gate passage, permission, or assurance; their consumer-side verifier or policy acceptance rule is part of the relying context, not implied by source-carrier presence. LLM citation and generated-explanation practice requires claim-bound attribution alignment before operative claims are relied on. A.10 adopts issuer, holder, verifier, status, currentness recoverability, status-register recoverability, and claim-bound attribution as evidence-provenance-path invariants, adapts credential practice, provenance practice, attestation practice, model documentation, data documentation, register-backed status display, and generated-explanation practice as FPF inputs for role-assignment or status-related source relations and carrier relations, and rejects visual display, copied text, generated text, provenance mark, credential display, register excerpt, or attestation form as evidence of an operative action invitation, gate, role assignment, status assertion, work occurrence, assurance, or bounded work effect without the source relation named by value.

Practical result from that cited practice: provenance, attestation, credential, status-register, and generated-source practice rejects the shortcut that provenance means truth, safety, release, permission, or assurance. The local A.10 result is bounded origin, history, build, holder or status currentness, generated-claim source mapping, bounded evidence use, unsupported attempted use, and reopen when the verifier, trust model, status or currentness rule, source mapping, or source-order relation changes.

#Relations

• Builds on: A.1 Holonic Foundation; A.3.4 Transformation; A.10 evidence-use and provenance relation discipline; A.14 Advanced Mereology; A.15 Role–Method–Work Alignment; A.2 and A.2.1 for role values and role-assignment relations; C.2.1 and E.17 for episteme, publication, carrier, and view separation.
• Constrains / used by: current composition, transformation, method, temporal, and work operators only when the governing pattern for that operator is named by value; B.1.1 Dependency Structure and Relation Grounding where current dependency-structure claims remain active.
• Enables: B.3 Trust Calculus (R inputs, CL inputs, auditability); B.4 Canonical Evolution Loop (clean DesignRunTag bridges).
• Coordinates with: C.28 when an evidence-provenance path is used for a causal-use relation; A.10 carries the evidence-provenance path, while C.28 governs the causal-use question, CausalEvidenceSupportBasis value, identification, realizability, bounded use, and unsupported attempted use.
• Coordinates with: A.2.4 when evidence-role or status-role source wording around an episteme needs first-use evidence-use or status-use relation slots before the full A.10 evidence-provenance graph relation is written.
• Coordinates with: A.15 for work or reliance disposition, A.6 for mixed boundary wording, B.3 for assurance, A.21 for OperationalGate(profile), GateDecision, and DecisionLogRef, A.20 for ConstraintValidity status or witness, A.2.9 for speech-act refs, A.2.8 for commitments, and A.15.1 for work occurrences. A.10 supplies evidence-provenance paths for the source relations or governing pattern refs consumed by those neighboring patterns; it does not create their gate decision, commitment, role effect, status effect, work-occurrence, assurance, bounded work effect, or bounded reliance effect.

#Older source text interpretation and neighboring-pattern notes

Older source texts may use names such as manifest, release manifest, creator, observer, symbol register, SCR, RSCR, MIC, or evidence path without the current FPF distinctions. Treat those names as recovery prompts, not as live vocabulary to copy unchanged.

Use these recoveries:

• a source register used for evidence carriers becomes an evidence-provenance entry with carrier identity and source-currentness fields;
• a release-context source register becomes a context-adapted evidence-provenance entry when the bounded context, identifiers, and hashes matter for publication or release use;
• an internal creator or observer used as evidencer becomes evidence-producing work, evidence-interpreting work, source-maintenance role assignment, verifier assignment, or quote-only source wording according to the claim being made;
• a method instantiation note is a method relation or work relation only when it states the U.Method, the U.MethodDescription ref or method-description source publication ref, ordering relation when relevant, and work-trace relation;
• resource rosters in Γ_work remain separate from evidence-carrier registers; cite meter, log, or observation carriers through the evidence-provenance graph.

When an older source text also claims approval, permission, gate passage, assurance, causal authority, measured comparability, representation shift, or publication-face effect, keep A.10 to the evidence-provenance graph relation and apply the neighboring governing pattern for that extra claim.

#Evidence carriers for quantum-like statements

Use A.10 when a quantum-like statement needs evidence rather than only a local modeling note. The practical question is not "is this quantum-like source impressive?" but "which carrier evidences which minimal claim, under which time window and method?"

Evidence-relation checks:

1. State the minimal state, probe, export, or viability claim being evidenced.
2. Pin the concrete carriers: source, trace, dashboard export, report, observation, metric, work result, model output, interview, survey, or incident record.
3. State the evidence-producing role and method: who or what produced the carrier, by which method, probe, measurement, or work act.
4. State the time window, decay condition, and reopen condition.
5. State what the carrier does not show, including the most relevant rival explanation that remains plausible.
6. Choose the next pattern: stay in A.10 for carrier evidence relation, apply B.3 for assurance claims, apply C.16 for measurement admissibility, apply F.9 for bridge or export loss, or apply a C.26.* pattern for the remaining probe, state, or envelope question.

For probe-coupled, distributed-state, bridge-loss, measurement-frame, or viability-envelope statements, include at least:

Useful outputs:

• a local evidence note when the claim only guides discussion;
• an evidence-provenance entry or context-adapted evidence-provenance entry when the claim enters a published assertion;
• a B.3 assurance tuple when the claim will feed readiness, audit, release, compliance, or comparative assurance;
• a neighboring-pattern note when the carrier shows only ordinary measurement, bridge loss, or work enactment.

Do not let the label quantum-like carry evidence weight by itself. The evidence graph carries the claim; the math lens only explains what representational mistake the evidence is being used to avoid.

#C.29 mathematical-lens use relation

If a mathematical lens needs evidence relation, write the evidence-provenance path, source currentness, provenance, and any model-card or datasheet evidence use in A.10. A C.29 output may state only the C.29-local lens-use value for the mathematical-lens use claim; it is not an evidence-provenance path, currentness proof, provenance record, or evidence-carrier substitute. Assurance or release confidence goes to B.3; measurement construction or comparability goes to C.16.

#A.10: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 direct governing 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 direct governing 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.

#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 direct governing 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:
  E24UKDecisionRef:
  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 direct governing 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 in a role, transformer, source-maintenance, carrier, or boundary slot is renamed as if the slot label created a new universal kind.
• 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.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

#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 changed holon from the acting system or candidate acting system. Then use the direct owner for the current claim: A.3.4 for bounded transformation, A.15 and A.15.1 for method and work, A.2.1 and A.2.7 for role assignment and role relations, 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 that holon's super-holon.

What this buys. Self-action wording becomes a reviewable relation among a changed holon, an acting system in role, method or work claims when current, boundary-crossing relation when current, and evidence when current.

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 the role assignment or role relation, use A.2.1 and A.2.7.
• If the current question is evidence independence or source use, use A.10 and the evidence or source-use owners.
• 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 system is 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, the acting side and the changed holon must be recoverable as distinct slot fillers for that claim. When ordinary language says "self-", split the larger holon into 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 system in role changed which holon under which conditions.
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:
  changedHolonRef:
  actingSystemRef: U.System or candidate acting system admitted by direct pattern
  actingRoleAssignmentRef:
  boundedContextRef:
  transformationRef?: U.Transformation
  methodRef?
  methodDescriptionRef?
  workPlanRef?
  workOccurrenceRef?
  holonBoundaryCrossingRelationRef?
  evidenceRelationRefs?
  strongerOwnerRefs:

The acting system and the changed holon are distinct slot fillers for the current change-bearing claim. They may be parts of a larger holon, and they 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. It names which direct owner governs each neighboring claim.

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) and [A.2.7](/generated/patterns/A.2.7) when role assignment or role relation 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 a larger holon and at least two distinct positions inside it:

ReflexiveSplit@Context:
  containingHolonRef:
  actingPartOrSubsystemRef:
  changedPartOrSubsystemRef:
  boundedContextRef:
  holonDelimitationRelationRefs?
  holonBoundaryCrossingRelationRef?
  actingRoleAssignmentRef?
  transformationRef?
  methodRef?
  workOccurrenceRef?
  evidenceRelationRefs?

The split is a modeling move, not a claim that the two positions are always permanent physical modules. They can be stable subsystems, temporal phases, organizational assignments, software components, or another directly governed structure. If the split relies on parthood, use A.14 and C.13. If it relies on role assignment, use A.2.1 and A.2.7. If it relies on temporal phases, use the temporal owner.

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", recover the acting system in role and the object that changed:

• a publication file or representation changed;
• a source record changed;
• an episteme slot relation changed;
• a claim relation, reference relation, or publication-use relation changed.

Use C.2.1, E.17, E.17.2, source-use, publication-use, and evidence owners for the episteme or publication side. A.12 only prevents the sentence from assigning agency to the episteme.

#No Super-Holon Inference

A system changing another holon does not become that holon's super-holon. Manufacturing, teaching, measurement, repair, control, telemetry, or source use can be boundary-crossing, transformation, work, evidence, or publication-use relations without being part-whole relations.

Use part-whole owners 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 or the direct evidence and assurance owner. 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."

Recovered A.12 use:

ActingSideExternalization@DocumentBuild:
  changedHolonRef: publication file or episteme slot relation under direct owner
  actingSystemRef: build script or editing system
  actingRoleAssignmentRef: cross-reference update role in DocumentBuild
  workOccurrenceRef: build run, if A.15.1 is current
  evidenceRelationRefs: build log, diff, validation check, or stronger evidence owner

The document does not act. If the changed object is a publication form, use publication owners. If the changed object is a claim-bearing episteme relation, use episteme owners.

#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:
  changedHolonRef: workpiece
  actingSystemRef: lathe
  actingRoleAssignmentRef: machining acting system
  transformationRef: bounded machining transformation, if A.3.4 is current
  workOccurrenceRef: machining work occurrence, if A.15.1 is current
  holonBoundaryCrossingRelationRef: cutting force, fixture relation, control relation, or material-removal relation under direct owner

The lathe can transform the workpiece without being the workpiece's super-holon. Use part-whole owners only if the workpiece is independently admitted as part of a containing holon.

#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; role assignment lives in A.2.1 and A.2.7; evidence lives in A.10; part-whole admission lives in A.1, A.14, and C.13. A.12 only supplies the acting-side split needed before those owners can be used cleanly.

#SoTA-Echoing

#Relations

• Builds on: A.1 for holon and system admission, A.2.1 for role assignment, A.2.7 for role relation structure, 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 upon the foundations laid in the FPF Kernel to provide that definition. A.1 established that only a U.System can be the bearer (holder) of behavioral roles. A.2.1 defined the universal U.RoleAssignment (Holder#Role:Context) as the canonical way to assign roles. A.3 and A.12 defined the TransformerRole@Context role value and the principle of acting-side externalization.

The intent of this pattern is to:

1. Formally define agency not as an intrinsic type of holon, but as a contextual Role Assignment.
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) and create conflicts with the dynamic nature of roles. A system might act agentively in one context and as a passive component in another; a static type cannot capture this.
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: it defines agential participation via U.RoleAssignment (A.2.1), makes agency measurable with a dedicated Characterization, and provides a didactic summary via a graded scale.

#The Core Definition: Agential participation as contextual role assignment

An ordinary-language "agent" in FPF is not a fundamental type. When the term is admitted, it is a convenience term (a Register 1 / Register 2 label) for a specific Contextual Role Assignment (U.RoleAssignment):

AgentialParticipation ≍ U.RoleAssignment(holderRef: U.System, roleRef: AgentialRole@Context, boundedContextRef: U.BoundedContext)

This means the acting holder is a U.System that currently bears AgentialRole@Context within a specific U.BoundedContext.

• No root Agent kind: To be clear, FPF does not add a base kind for "agent" beside U.System and U.Episteme. This avoids type inflation and preserves the dynamic nature of roles.
• Epistemes Cannot Hold Work-Facing Agential Roles: As the holderRef must name a U.System, this definition constitutionally forbids U.Epistemes from being acting holders, preventing the "episteme-as-actor" category error.
• Canonical Syntax: The technical notation is System#AgentialRole:Context.

#The AgentialRole and its Specializations

• AgentialRole@Context: This is the abstract role value for goal-directed action within a context. It is not a separate root kind.
• Specialized Roles: More specific behavioral role values like TransformerRole@Context and ObserverRole@Context specialize AgentialRole@Context. They describe what kind of agential action is being performed at a given moment.
  • A system holding TransformerRole@Context is currently modifying another holon.
  • A system holding ObserverRole@Context is currently gathering information. This creates a clean role-value hierarchy: a TransformerRole@Context assignment is agential, but an agential assignment is not always transformational; it could be observing, planning, or idle.

#Measuring Agency: The Agency Characteristic Profile and the Spectrum

Agency is not a binary switch; it is a multi-dimensional spectrum of capabilities. FPF models this using C.9 Agency Characteristic Profile, a characterization pattern that attaches a set of measurable properties to a U.RoleAssignment.

The agency-characteristic profile is grounded in contemporary research (e.g., Active Inference, Basal Cognition) and includes the following key characteristics. Each is measured for a specific holder system in a specific context and must be backed by evidence (A.10).

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.

#Context-bounded task-family specialization claims

When work shifts to a new TaskFamily, describe the holder as acquiring context-bounded task-family specialization rather than as becoming more generally intelligent in the abstract. The same holder may carry different task-family specializations across different task families without becoming a new U-kind. Breadth across unrelated task families is not the adaptation-signature claim here; the adaptation-signature claim is time-to-usable specialization on the declared task family and work target under a named work-measure threshold, adaptation budget, and freshness or provenance basis.

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 universal pattern of agency, defined as a Contextual Role Assignment and measured by the agency-characteristic profile, manifests across all domains. The following table demonstrates its application to the FPF's two primary archetypes: a U.System and a collective U.System (a team), while explicitly showing why a U.Episteme cannot be an acting holder.

Key takeaway from grounding: This table makes the abstract model concrete. It shows that the FPF agency model can precisely differentiate between simple controllers and complex learning systems. It also reinforces the Strict Distinction principle: the ISO standard (U.Episteme) is a crucial justification (justification?) for actions by a role-assignment holder such as the DevOps team, but it is never an acting holder itself.

#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: By defining agential participation as a Contextual Role Assignment, the pattern avoids the ontological pitfalls of creating a new base type. It fully embraces the FPF's core architectural principle of separating substance (holder) from function (role) within a context. This aligns with best practices from foundational ontologies (like UFO) and the principles of Strict Distinction (A.7).
• 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 Role Taxonomy: Provides the universal Contextual Role Assignment (U.RoleAssignment) mechanism.
  • 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.
• Instantiates:
  • C.9 Agency Characteristic Profile, which provides the formal definitions for the characteristics (BMC, PH, etc.).

#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 a part-whole claim must distinguish component, member, portion, aspect, or phase before downstream architecture, work, assurance, or U-kind admission relies on that claim.

Use this when. Use this pattern when a text says that something is part of something else, a collection member, some amount of the same stuff, an aspect of one holon, or the same holon during a time interval, and a wrong relation kind 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 mereology catalogue that lets B.3.5 and C.13 ground structural claims without inventing a new public relation vocabulary.

Not this pattern when. Not this pattern when the current question is only a constructive trace (C.13), Working-Model assurance grounding (B.3.5), meta-holon transition (B.2), temporal dynamics without a phase-of claim, or a general U-kind admission question (E.24.UK).

#Problem frame - why an advanced mereology?

FPF’s holonic modelling relies on part–whole relations to build structural and conceptual holarchies for admitted holons such as systems, epistemes, work occurrences, bounded contexts, disciplines, and methods. But U.Holon is not a synonym for every bounded object. U.Role is a governed root U-kind, not an admitted holon kind. U.Method is a non-agentive holon kind, but submethod assembly is owned by method-composition patterns, not by A.14 structural component mereology. Role relation structures, method relation structures, method descriptions, work plans, and work occurrences enter A.14 only through their direct governing patterns and admitted carriers. Early drafts distinguished structural vs. conceptual parthood (e.g., ComponentOf, ConstituentOf) but practical modelling kept hitting two recurrent gaps:

1. Quantities vs. parts. Engineers routinely need “some of the fuel”, “the first 10 pages”, “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. Change vs. replacement. Authors need to say “the prototype before calibration”, “v2 of the spec”, “shift 1 vs. shift 2 of the same run”. That is not a new whole; it is a phase of the same carrier across time.

This section introduces two normative sub‑relations of partOf that close those gaps and lock them to the rest of the kernel:

• PortionOf — metrical, measure‑preserving parthood of stuffs and other measurables.
• PhaseOf — temporal parthood of the same carrier across an interval.

It also restates guard‑rails that keep role values outside holon mereology and keep method values outside A.14 structural component mereology, while allowing method holarchy through method owners such as A.3.1 and B.1.5. Describing epistemes such as U.MethodDescription and U.WorkPlan use ordinary episteme parthood and versioning like any other U.Episteme. It also clarifies how MemberOf fits: membership and collection-as-whole grounding start with A.14, C.13, and B.3.5 as appropriate; acting collective systems require U.System admission plus role, method, work, and evidence owners; whole reidentification uses B.2 only when existing-whole explanations fail.

Publication note (Working-Model first). Read A.14 together with E.14 Human-Centric Working-Model and B.3.5 CT2R-LOG: publish the direct relation claim in the Working-Model layer and, when assurance is sought for a structural claim, link that assertion downward to one current C.2.1 construction-trace episteme in the Compose-CAL Γ_m sum, set, or slice form. The trace reports exact participants, direct relation occurrences, the applicable construction rule, and identity or reidentification conditions. It creates none of them; order and time remain outside mereology.

#Problem — what breaks without these distinctions?

If we only have “generic partOf” (plus Component/Constituent), four 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. Temporal smearing. Flattening “before/after”, or “v1/v2” into one timeless whole collapses history; Γ_time and Γ_method cannot justify order‑sensitive properties; audits cannot reproduce conditions.

3. Identity confusion. Modelling “new version” as “new component” either breaks identity (it is still the same holon evolving) or hides a Meta‑Holon Transition when identity really changes.

4. Role leakage. Functional/organisational roles sneak into part trees (“the PumpRole is part of the plant”), violating A.15 and making structural reasoning brittle.

#Forces

#Solution — extend the mereology catalogue, keep it clean

A.14 defines two additional sub‑relations of partOf and re‑affirms the firewall between mereology and the role/recipe layer:

1. PortionOf — for measured parts of a whole (stuffs and other extensives).
2. PhaseOf — for temporal parts of the same carrier.
3. No role values in holon mereology; no method values in structural component mereology. U.Role is not an admitted holon kind. U.Method is a method holon, but its submethod assembly is governed by method-composition owners, not by A.14 ComponentOf or structural partOf. A U.MethodDescription is an Episteme and may be versioned or structured; U.Work occurrences may have work-occurrence parts under A.15.1; neither case replaces method holarchy.
4. MemberOf stays, but collection identity and acting-collective claims use direct owners. MemberOf remains available to state exact collection-membership occurrences. After the collection, its identity rule, and those memberships are independently grounded, Γ_m.set may narrate their construction account and B.3.5 may link that account when publication assurance is current. Neither the gathering narrative nor its trace creates a membership. An acting collective system uses U.System admission plus role, method, work, and evidence owners. Whole reidentification uses B.2 only when existing-whole explanations fail.

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 x ⟂ y (no overlap) and both PortionOf y, then μ(x ⊔ y) = μ(x)+μ(y) and x ⊔ y PortionOf y.
• 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. ✔ “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 (Partial order). PhaseOf is reflexive, antisymmetric, transitive (on the same carrier).
• PHA‑2 (Coverage). The whole is the union of its maximal, non‑overlapping phases over its lifetime interval.
• PHA‑3 (No paradoxical overlap). Phases of the same carrier do not overlap in time; overlapping variants require PhaseOf on aspects or different carriers.
• PHA‑4 (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‑5 (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). ✔ “Spec v2” — PhaseOf(Spec_v2, Spec), on the MethodDescription episteme. ✔ “Shift 1 of the same batch run” — PhaseOf(Work_shift1, Work). ✘ “Prototype vs. production unit” — likely different carriers; use ComponentOf/ConstituentOf or MHT per criteria.

#CT2R‑LOG & Compose‑CAL handshake (normative link)

• A structural relation claim published in the Working-Model layer SHALL, when assurance is required, link through tv:groundedBy to one current C.2.1 construction-trace episteme in the Γ_m.sum | Γ_m.set | Γ_m.slice form (see B.3.5 and C.13). The direct relation pattern decides whether the occurrence obtains and how it is identified; the candidate's direct identity or reidentification rule decides continuity. The trace only reports that basis.
• PhaseOf is temporal parthood; it SHALL NOT be grounded through Γ_m. Its assurance follows identity-through-time criteria (CC-PHA-1..3) and Γ_time ordering (B.1.4).
• MemberOf remains non-mereological (CC-MEM-2). A set trace is truthful only after one exact collection, its identity rule, and the exact direct membership occurrences are grounded; no ComponentOf inference follows.

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 your sentence is about who does what, how it is done, or what happened when (role, method, or run), you are likely in A.15. If it is about the document or carrier (its pages/sections/versions), you may still be in A.14 (Episteme mereology).

#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 all sound like "part of" while naming different relation kinds. The repair is not a larger part tree. Recover the EntityOfConcern and choose the relation kind: component, constituent, portion, phase, member, role assignment, method description, work occurrence, evidence relation, or transformation relation.

It also corrects representation bias. A BoM row, figure, graph edge, table row, document section, dashboard item, or architecture view may publish a part-whole claim, but the publication form is not the part-whole relation itself. The live A.14 claim is about the relation between holons, epistemes, carriers, portions, phases, or collection members, with mathematical or publication descriptions kept in their own slots.

#Conformance Checklist - type guards

#Global firewall and scope

#PortionOf guards

#PhaseOf guards

#Grounding and validation (normative)

Note. Property names and trace semantics are defined in the CT2R‑LOG / Compose‑CAL.

#MemberOf minimal semantics (non‑mereological)

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

#Relation-use decision procedure

Step 0 — Firewall check. If your sentence is about who does what, how it is done (role or method), or what happened when (run or work occurrence), you are not in A.14 merely because ordinary speech names a thing. Use the role, method, work, or evidence owner. If it is about the carrier episteme (pages/sections/versions of an SOP/algorithm/spec), or about a dated work occurrence with recovered work-part relation, A.14 may participate through that admitted carrier.

Step 1 — Is it measured stuff? If yes, pick PortionOf. Confirm μ is declared (CC‑POR‑1/2). Test additivity on a toy split (CC‑POR‑3). If flows cross a boundary, remodel as interactions, not portions (CC‑POR‑4).

Step 2 — Is it a discrete inside part? If yes, pick ComponentOf (physical) or ConstituentOf (conceptual). Do not use PortionOf here.

Step 3 — Is it the same carrier at a time slice? If yes, pick PhaseOf. Verify identity criteria and non‑overlap (CC‑PHA‑1/2/3). If criteria break, escalate to B.2 (CC‑PHA‑4).

Step 4 — Is it a membership statement? Use MemberOf only; avoid any part‑inferences (CC‑MEM‑2). If you need a collection as a whole, use C.13 (Γ_m.set) and B.3.5 when assurance grounding is current. If you need collective action, first admit an acting collective U.System, then use the role, method, work, and evidence owners.

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 if it were structurally integrated into the whole.
• Role as part. A system plays a role, and the role label is placed inside a part tree.
• Method as part. A method value, recipe, or algorithm is treated as a component instead of using method, method-description, work, or transformation owners.
• Portion without measure. Some amount of fuel, data, time, or text is named as a portion without a measure kind, unit, and additivity condition.
• Phase as replacement. A version or time slice is treated as a new component when the carrier identity continues, or as the same phase when the identity criteria fail.
• Diagram or trace as relation. A visual breakdown, graph, table, construction trace, or validationMode is used as proof that parthood obtains or that the whole has one fixed identity. Recover the direct relation occurrence and the candidate's identity or reidentification rule first; use the publication and trace only as inspectable accounts.

#Pedagogy aids (non-normative)

Two‑minute checklist for practitioners

1. Do I see "process", "procedure", "policy", or "script" used to mean enactment? — then A.15. If it names a carrier episteme whose structure/version is being discussed, A.14 may apply.
2. Does every PortionOf have a declared μ and unit?
3. Do phases cover a lifetime without overlap for the same aspect?
4. Are any roles/recipes appearing as parts? If yes, stop and refactor.

#Consequences

Benefits

• Predictable composition. Σ‑additivity for portions and identity‑through‑time for phases make Γ‑proofs straightforward.
• History without confusion. Temporal slicing is explicit and audit‑ready; no paradoxical overlaps.
• Cleaner integration with roles and recipes. The firewall prevents “functional object” creep into structure.
• Compatibility with engineering practice. Mirrors product breakdown (components) vs functional breakdown (roles) vs material stocks (portions) vs versioning (phases).

Trade‑offs / mitigations

• Modelling energy. Authors must pick μ and declare units; provide a short μ‑catalog per project.
• More relation names. Two extra sub‑relations increase vocabulary; mitigated by the decision table (§ 6) and spot‑tests (§ 9).
• Escalation discipline. Deciding PhaseOf vs MHT requires judgement; A.14 provides criteria, and B.2 captures true re‑identification.

#Rationale

A.14 exists because part-whole words carry identity, aggregation, measure, time, and assurance commitments. The pattern keeps those commitments in the relation kind instead of letting everyday nouns, diagrams, or breakdown tables decide ontology. Component, constituent, portion, phase, and member claims can then support holon, episteme, architecture, and evidence work without smuggling role, method, work, or publication claims into mereology.

#SoTA-Echoing

• Metrical mereology advances (e.g., recent work on quantity‑based parthood and additivity) motivate PortionOf with explicit μ and Σ‑laws, preventing the classic “stuff as components” fallacy.
• Temporal parts & identity through change (renewed treatments in analytic metaphysics and formal ontology) motivate PhaseOf with coverage/non‑overlap and escalation when identity criteria fail.
• Engineering ontologies (BORO lineage, Core Constructional practice, ISO 15926 family) keep a strict separation between functional breakdowns (our Roles) and product breakdowns (our Components), with stock/consumable modelling (our Portions) handled by quantities, not by component trees.
• Knowledge-episteme edition histories in contemporary MBSE and open-science practice use explicit versioning (our PhaseOf) and provenance-preserving composition (our ConstituentOf).
• The net effect is a minimal‑sufficient catalogue: two added sub‑relations close real modelling gaps while preserving parsimony, didactic clarity, and Γ‑compatibility across domains.

#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: A.15, A.15.1, A.3.1, A.3.2, and A.3.4 when the source wording is about role 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

#Role–Method–Work Alignment

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

At a glance. This pattern is the enactment-alignment pattern for engineer-managers when the real confusion is not "what component is this" but who is responsible, how the work is supposed to happen, when the plan applies, and what actually happened.

Use this when. Use this pattern when the real job is to separate role, method, plan, holder U.Capability instance, any capability statement or currentness assessment relied on, capability-fit checks, and performed work before a team treats one cue, one schedule, one display, one copied or generated statement, or one document as if it already counted as the role assignment, the method, the work plan, execution evidence, or the work itself.

Start here when. The dominant ambiguity is role vs method vs schedule vs performed work occurrence, and the team keeps arguing over encountered "process" wording without separating recipe, plan, capability, and executed work.

First output. One explicit separation of U.Role, U.Method, U.MethodDescription, U.WorkPlan, U.Work as the admitted kind, one dated Work occurrence admitted under that kind, and any separate assertion or description about it, plus the shortest traceable chain that already exists from U.RoleAssignment through the governing U.Method and its methodDescriptionRef or U.MethodDescription reference to the intended U.WorkPlan or actual Work occurrence, or an explicit source-relation gap that blocks admission of the claim.

Working enactment-alignment sequence. Role, method, plan, and work confusion -> separate the role, holder, role-taxonomy episteme, effective reference scheme, method description, intended U.WorkPlan, U.Work kind, actual dated Work occurrence, and any record about it -> choose proceed, plan, bounded probe, narrow, apply the direct governing pattern for any non-A.15 claim, or stop -> output the smallest alignment frame needed for the next work-family use -> use A.15.4 only when an encountered episteme publication, display, credential view, explanation, copied statement, provenance mark, dashboard tile, schema wording, API wording, or composed source-relation chain begins to carry or justify a work claim or reliance claim.

Working alignment applications.

1. Name the role, holder, exact role-taxonomy episteme, and effective reference scheme under repair.
2. Name the method or method description that is meant to govern the work.
3. Name the intended U.WorkPlan, or identify the actual dated Work occurrence admitted under U.Work and keep any assertion or record about it separate.
4. Choose the next governed use: proceed inside the recovered relation, plan, run a bounded reversible probe, narrow scope, apply the governing FPF pattern and project-side FPF kind and reference named by value for the claim or effect being made, or stop.
5. If a reliance appearance such as a display, credential view, copied approval, generated explanation, publication face, or cue is being used by appearance for a work claim or reliance claim before the governing pattern position is named, apply A.15.4 work-relevant appearance-based reliance repair to that claim; keep A.15 only for the separation among U.Role, U.Method, U.MethodDescription, U.WorkPlan, U.Work as the admitted kind, each actual Work individual admitted under it, and every separate episteme about such an occurrence.

Action-pattern protection. This pattern is not about classifying encountered publications, displays, or cues. It keeps role, method, plan, holder U.Capability instance, separately governed capability-support records and relations, capability-fit checks, and performed work distinct so the acting engineer-manager can choose the next admissible work-family or reliance use. Work-relevant appearance-based reliance repair is handled by the related A.15.4 cluster member.

Minimum sufficient governed use. Choose the minimum sufficient governed use, recover only the project-side FPF kind and reference named by value needed for that use, and do not raise the claim beyond that recovered relation, source, or admissible-use boundary.

Recovered governing-reference sufficiency condition. If the required project-side FPF kind and reference named by value is present and its scope and window match the role, method, plan, or work-family claim under repair, proceed inside that recovered scope and window. If not, narrow scope, run a bounded reversible probe, find the missing source relation, or create only the smallest A.15.4 repair request, decision-request record, prospective work-plan entry, missing-source-relation note, or missing-source admission block needed for the next governed use.

Ordinary use. If the team only needs to separate role, method, plan, holder U.Capability instance, capability-fit checks, and performed work for orientation or planning, one separation sentence or small working card is enough.

Reliance-bearing use. Use the fuller alignment frame when a reliance appearance is about to guide planned work, performed work, role attribution, role-state attribution, release reliance, disputed responsibility, or use under another role taxonomy or reference scheme. Use A.15.4 when the issue under repair is whether that appearance exposes the project-side FPF kind and reference named by value required for that work claim or reliance claim.

Stop condition. Stop once the separation changes no next admissible work-family use or reliance use and blocks no concrete overclaim about role, role-state, method, plan, work, approval, evidence, or release.

Admissible-use examples.

Alignment frame in plain terms. One alignment frame that keeps U.Role, U.Method, U.MethodDescription, U.WorkPlan, U.Work as the admitted kind, one actual Work individual admitted under it, and any episteme about that occurrence distinct, while exact performedUnderAssignment and enactsMethod relations connect the occurrence to its U.RoleAssignment and U.Method; the admitted holder system is the actual performer under the assignment. This is not a single work occurrence, checklist, language-style repair pattern, or mere cue note.

First admissible work-family use in plain terms. Keep role value, holder assignment, semantic method, method-description reference, intended work plan, and dated performed work distinct while making the chain between them inspectable enough for enactment, audit, and source-relation recovery.

What goes wrong if missed. Teams collapse role, recipe, plan, capability, and performed work occurrence into one fuzzy "process" label from project material, then mistake documentation for execution, capability for evidence, schedule for occurrence, or a narrower briefing for the relation that makes work admissible.

What this buys. One inspectable enactment frame that lets a team ask who held what role, which method governed, what plan existed, and what work actually occurred before treating follow-on work, blame, or approval as if those distinctions were the same.

Not this pattern when. Not this pattern when the honest need is only one dated work occurrence (A.15.1), only planning or schedule baseline (A.15.2), only work-entry readiness or full-kit preparation (A.15.5), only a cue note that has not yet become an enactment-alignment question (A.16 or A.16.1), only boundary wording or policy wording without a role-method-work question under repair (A.6 or A.6.B), or work-relevant appearance-based reliance repair for a display, credential view, copied approval, generated explanation, publication face, or similar reliance appearance (A.15.4).

Related project records and governing patterns. A.15.1 governs dated Work occurrences admitted under U.Work and the boundary to separate assertions or records about them; A.15.2 governs schedule or baseline planning records, A.15.3 slot-filling plan items, A.15.4 work-relevant appearance-based reliance repair, A.15.5 work-entry readiness and full-kit preparation, B.5.1 Explore -> Shape -> Evidence -> Operate for project progression, F.11 method and work vocabulary alignment across contexts, and F.17 the human-facing work sheet.

Causal-use work boundary. Realized counterfactual-sampling work, counterfactual randomization, intervention assignment, target-trial emulation work, and causal evidence collection remain separately represented here as U.MethodDescription epistemes, U.WorkPlan epistemes, and world-side Work individuals admitted under U.Work together with their exact role and method relations. A.15 can say who performs which sampling or intervention work under which method and role; it does not make the resulting causal use admissible. C.28 governs the causal-use question, CausalityLadderRung, causal estimand, CausalEvidenceSupportBasis, counterfactual sampling realizability, and supported use and unsupported use.

Related-record mistakes. If the first honest cue is still only a cue, keep it under A.16 or A.16.1; if the question under repair is boundary wording, promise, agreement-like service, or policy wording, recover the corresponding A.6 boundary-claim record; if you need one executed occurrence rather than the alignment frame, recover the dated Work occurrence under A.15.1 and create or cite a separate assertion or record only when that episteme is also needed; if a reliance appearance is being used for a work relation or reliance relation, use A.15.4.

Boundary to coarsened renderings. A lighter briefing, summary, redacted note, or coarsened rendering may orient work or cue attention. It becomes sufficient for work execution, plan use, approval, gate decision, or execution evidence only when the required method, plan, approval, gate, or evidence source remains explicit and reopenable. Treat the coarsened-rendering relation through A.6.3.CSC Controlled Semantic Coarsening when the rendering itself changes what can be relied on.

Use boundary. Use A.15 when the current project question needs role-method-work alignment. If the current claim is one single work occurrence, A.15.4 repair note, wording repair, assurance claim, or encountered "process" label, use the governing pattern for that claim and keep only the A.15 separation that remains needed.

#Problem frame

In any complex system, from a software project to a biological cell, there is a fundamental distinction between what something is (its structure), which role a holder is assigned under an exact role-taxonomy episteme and effective reference scheme (U.Role and U.RoleAssignment), how work is done (U.Method and U.MethodDescription), which holder U.Capability instance is relied on (A.2.2), which statement, evidence relation, or currentness assessment supports that reliance, which separate capability-fit, threshold, gate, or admission check is applied when fit is current, what work is intended (U.WorkPlan), which world-side dated Work occurrence happened (an individual admitted under U.Work), and which separate assertion or record describes it. Confusing these distinctions is a primary source of design flaws, budget overruns, and failed projects. Teams argue over encountered "process" wording without clarifying whether the FPF object under repair is a U.Method, a U.MethodDescription, a holder U.Capability instance, a statement about that instance, a separate capability-fit condition, a U.WorkPlan, an actual Work occurrence, or an episteme about that occurrence.

This pattern provides the canonical role-method-work enactment alignment in FPF. It applies the Strict Distinction Principle (A.7) to the passage from holder-in-role assignment and selected method to intended U.WorkPlan, an actual Work occurrence admitted under U.Work, and any separate episteme about it, without making A.15 the whole strict-distinction ontology. It weaves together current governing relations into a single, coherent model:

• A.2 and A.2.1: Provide enactment-facing U.Role values and U.RoleAssignment as the typed assignment relation with exactly four generic participants: holder U.System, U.Role, exact role-taxonomy episteme, and effective U.ReferenceScheme. The actual assignment extent is the maximal continuous interval over which that relation obtains; declared windows and justification or source claims remain assertion or description content.
• A.15.2 and A.15.1: Separate U.WorkPlan intent from actual dated Work occurrences admitted under U.Work, and separate both from assertions or records that designate them.
• A.3.1 and A.3.2: Separate U.Method from U.MethodDescription, so recipes, algorithms, procedures, and encountered "process" wording do not become performed work by word choice.
• A.3.4: Provides U.Transformation for bounded change under conditions when the actual change, affected entity, pre/post state, mechanism, method, or work relation is current.
• A.10, C.2.1, and E.17: Keep evidence relations, source relations, publication relations, and carrier relations outside the work-facing role assignment unless a system or acting holon is actually assigned a role for performed work.

The intent of this pattern is to establish a normative, unambiguous vocabulary and set of relations for connecting holder-in-role assignment, recovered method, method-description reference, holder U.Capability instances when relied on, separate capability statements or currentness assessments when those are used, separate capability-fit conditions when current, intended work plan, actual dated resource-consuming Work occurrences admitted under U.Work, and separate epistemes about them.

To keep plan-occurrence separation explicit, this pattern references A.15.2 U.WorkPlan for schedules and calendars and A.15.1 for admission under U.Work and identification of dated Work individuals. Ambiguous terms in project material, such as "process", "workflow", "activity", and "schedule", are handled by E.10 and E.10.ARCH: recover the object under wording repair first, then assign the wording to U.Method, U.MethodDescription, U.WorkPlan, the U.Work kind or one Work individual admitted under it, or another direct governing pattern.

Terminology note. The words action and activity are not normative kernel names by themselves. When a generic "doing" cue appears, recover the FPF object or kind being claimed: U.Method, U.MethodDescription, U.WorkPlan, one Work individual admitted under U.Work or the kind itself when kind-level classification is current, or a neighboring governed value such as U.Transformation, U.Dynamics, evidence relation, gate relation, source relation, or publication use.

#Problem

Without this formal framework, models suffer from a cascade of category errors:

1. Role-as-Part: A Role (e.g., AuditorRole) is incorrectly placed inside a structural parts list (ComponentOf), making the system's architecture brittle and nonsensical.
2. Specification-as-Execution: A MethodDescription (the "recipe") is treated as evidence that the work was done. This leads to "paper compliance," where a system is considered complete simply because its documentation exists.
3. Capability-as-Work: A team's ability to perform a task (Capability) is conflated with the actual performance of that task (Work). This obscures the reality of resource consumption and actual outcomes.
4. Work-without-Alignment: An instance of work is logged without a clear link back to the exact role assignment, recovered method, method-description reference, and capability-fit or admission condition that made it admissible, making the work unauditable and its results impossible to reproduce.
5. Ambiguous "process" or "activity" wording: The overloaded term "process" is used indiscriminately to refer to all of the above, creating a fog of miscommunication. Repair generic doing or activity terms through E.10 and E.10.ARCH to U.Method, U.MethodDescription (recipe), U.WorkPlan (schedule), one Work individual admitted under U.Work (performed occurrence), or another direct governing pattern.

#Forces

#Solution

Method and work governing-pattern cue. When encountered "process", "algorithm", "solver", "workflow", "procedure", or similar wording points to changing, producing, selecting, deriving, controlling, or maintaining an EntityOfConcern, use E.10.ARCH:3.1 to recover the object under wording repair first and then assign separately governed typed values. A.15 carries only the alignment among role, method, method-description, work-plan, and performed-work references. Formal substrate, mathematical-lens use, mechanism declaration or realization, evidence relation, gate relation, source relation, result, publication, and temporal claims are governed by their own patterns.

When methods are related to one another, A.15 keeps only the alignment use of that relation. The method-side object is the exact governed method relation structure under A.3.1, A.3.2, G.5, or a direct method-composition pattern when current. A method algebra, workflow graph, process calculus, matrix, category, embedding, or neural representation is a lens or method description over that structure, not a role relation, work plan, dated work occurrence, or assignment relation. The solution is a stratified alignment that cleanly separates semantic method, method-description reference, holder-in-role assignment, holder U.Capability instances when relied on, separate capability statements or currentness assessments when those are used, separate capability-fit conditions when current, intended work plan, and dated performed work. The work-facing assignment relation is U.RoleAssignment.

#The Core Entities: A Strict Distinction

FPF mandates the use of the following distinct, non-overlapping entities to model method, plan, and work enactment. Using them interchangeably is a conformance violation.

A) Role, Method, Description, Capability, And Plan Values:

• U.Role: A work-facing role value interpreted through one exact role-taxonomy episteme and effective U.ReferenceScheme. Expected contribution, responsibility, permission, commitment, obligation, capability-fit, and admission conditions are neighboring relations governed by their direct patterns; the role value is not the holder, assignment occurrence, method, capability, work plan, or work occurrence.
• U.Method: The run-independent semantic way of doing a kind of transformation or enactment. It is not a dated performance or its description.
• U.MethodDescription: A U.Episteme describing a U.Method; it may be expressed in an SOP, algorithm, proof, recipe, or other method-description publication.
• U.Capability: The A.2.2 admitted dependent durable U-kind for holder-dependent capability instances. A concrete instance is a U.System holder's ability to perform a work family or produce a result class within a declared envelope, measure set, qualification window, and currentness condition. A CapabilityStatement, evidence relation, source-use relation, or currentness assessment may support relying on that instance; a capability-fit condition may test it. The capability instance is not the method, method description, support record, fit predicate, work plan, or work occurrence.
• U.WorkPlan: A U.Episteme declaring designators and constraints for possible future Work occurrences, including windows, dependencies, intended performers by role, and budgets. A future Work occurrence does not yet exist merely because a plan refers to it - see A.15.2.

B) The Assignment Relation:

• U.RoleAssignment: The typed assignment relation for enactment-facing roles. Its generic signature has exactly four participant slots: holder U.System, assigned U.Role, exact role-taxonomy episteme, and effective U.ReferenceScheme. Its actual occurrence extent is derived as the maximal continuous interval over which those participants stand in the assignment relation. A declared assignment window, rationale, source, or selected BoundedModelUseStructure belongs to the receiving assertion, description, or use; none is an optional generic participant.

C) Performed Occurrence:

• U.Work: The admitted kind for concrete dated work-occurrence holons. One Work individual is a world-side, resource-consuming enactment of a U.Method by a holder under a U.RoleAssignment; it has its own temporal extent and stands in actual performer, method, containing-system, affected-referent, binding, and resource-use relations when they obtain. Capability-fit checks are evaluated against the holder for that occurrence. Any methodDescriptionRef, log, ticket, assertion, description, or performed-work record is a separate U.Episteme that may designate the occurrence and state those relations; it is not the occurrence. The assignment occurrence has its own actual extent, derived separately from uninterrupted obtaining.

Work individual and description boundary

U.Work is the admitted kind for dated work-occurrence holons. One Work individual is a world-side occurrence that stands in actual performedUnderAssignment, enactsMethod, temporal, executedWithin, affected-referent, binding, and resource-use relations when those relations obtain. The actual performer is the admitted U.System that fills the covering assignment's HolderSystemSlot; the assignment is the ground under which that system performed the Work. An assertion, description, log, ticket, or other record about that occurrence is a separate U.Episteme: it may designate the Work individual and state those relations, but it is neither the occurrence nor a Work individual.

Do not add a universal primaryTarget field, a local kind field, or an Operational/Communicative/Epistemic enumeration to the occurrence. Recover the exact affected-referent, transformation, speech-act or commitment effect, episteme-handling, production, delivery, acceptance, or other relation through its direct governing pattern. The words operational, communicative, and epistemic may remain use cues; they do not define local Work subkinds by enumeration.

Didactic Note for Managers: The "Chef" Analogy

This model can be easily understood using the analogy of a chef in a restaurant.

• ChefRole is the Role. It's a job title with certain expectations.
• A Cookbook (U.MethodDescription) contains the recipe for a Souffle. It's a piece of knowledge.
• The chef's skill in making souffles is their U.Capability instance. They have this skill even when they are not cooking, while a certificate or review about the skill is a separate support record.
• RestaurantRoles-2026 supplies the vocabulary for ChefRole, and Restaurant-A-Role-Scheme is the effective reference scheme. The restaurant rulebook is a separate episteme that may declare capability or work-admission conditions before cooking work is admitted; it is not a participant of the generic role assignment.
• The actual act of making a souffle on Tuesday evening is one Work occurrence admitted under U.Work. Its exact temporal relation and separately obtaining resource-use relations connect that occurrence to the 25-minute extent, eggs, butter, and consumed gas when those facts obtain. A kitchen log that states them is a separate episteme.

Confusing these is like mistaking the cookbook for the souffle. FPF's framework simply makes these common-sense distinctions formal and mandatory.

#The Canonical Relations: Connecting the Layers

The alignment uses precise relations only where they obtain. The diagram keeps the four generic U.RoleAssignment participants visible, keeps method description, capability fit, and work occurrence outside that assignment signature, and shows the derived actual-performer cue from F.6 on the single performed-work attribution edge rather than as a second relation. It presents method-description status as A.3.2 membership of the episteme, not as another edge.

graph TD
    subgraph Role Assignment
        H["holder H : U.System"] -- holder participant --> RA["assignment occurrence RA : U.RoleAssignment"]
        R["role value R : U.Role"] -- assigned-role participant --> RA
        RT["role taxonomy T : U.Episteme"] -- taxonomy participant --> RA
        RS["effective scheme S : U.ReferenceScheme"] -- scheme participant --> RA
    end

    subgraph Method and Capability
        M["method M : U.Method"]
        D["episteme D<br/>A.3.2 membership: U.MethodDescription<br/>EntityOfConcern = M"]
        Cap["capability C : U.Capability"] -- ability for method family --> M
        Fit[CapabilityFitCondition] -- tests declared measures of --> Cap
        Fit -- may cite --> Q[U.Characteristic value, Q-Bundle slot, or architecture-characteristic row]
    end

    W["Work occurrence W : U.Work"] -- "performedUnderAssignment<br/>(F.6 derives actualPerformerSystem(W, RA) = H)" --> RA
    W -- enactsMethod --> M
    style R fill:#fff2cc,stroke:#d6b656,stroke-width:2px
    style RT fill:#f8cecc,stroke:#b85450,stroke-width:2px
    style RS fill:#f8cecc,stroke:#b85450,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 Q fill:#fff2cc,stroke:#d6b656,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

• Capability-fit condition: A method description, work plan, or separately governed work-admission assertion may state that the holder under a U.RoleAssignment must satisfy a capability threshold or envelope for a method or work claim. The fit condition tests the holder's U.Capability instance and may cite declared capability measures, U.Characteristic values, Q-Bundle slots, or architecture-characteristic criteria rows. The role value does not own the capability, the support record does not become the capability, and the fit condition is not a second capability kind.
• A.3.2 membership for a method-description episteme: One already identified U.Episteme D is a U.MethodDescription when its exact EntityOfConcern resolves to M : U.Method and at least one substantive claim says how M is done. Saying that D describes M is shorthand for that constitution-and-membership result, not another binary description relation. This keeps the run-independent way of doing distinct from the description and any publication that exposes it.
• enactsMethod(W : U.Work, M : U.Method): One exact Work occurrence W admitted under U.Work stands in enactsMethod to method M admitted under U.Method. A separate performedUnderAssignment relation connects W to its role-assignment occurrence when that attribution obtains; the admitted system in the assignment's HolderSystemSlot is the actual performer. Capability-fit checks are evaluated against that holder for the occurrence; the U.MethodDescription remains a separate episteme, and any admitted source remains under its separate source-use relation.
• performedUnderAssignment(W : U.Work, RA : U.RoleAssignment): [F.6](/generated/patterns/F.6) owns this direct attribution relation, its obtaining and occurrence-identity rule, the derived actual-performer projection, and the deprecated-alias boundary; A.15 consumes that owner here. For one exact Work occurrence W and covering assignment occurrence RA, read the actual performer as admitted system H = actualPerformerSystem(W, RA) = RA.HolderSystemSlot, and use the relation only when H performed W under RA. The assignment is the ground, not the actor; its four fixed participants keep the holder system, role value, role-taxonomy episteme, and effective reference scheme recoverable. A performed-work record may state this attribution but constitutes neither occurrence nor the relation. Existing performedBy(W, RA) claims may be read only through the F.6 compatibility boundary after resolving H; do not author new claims with that spelling.

The assignment occurrence has the maximal continuous extent over which its four-participant relation obtains. A planned or asserted interval does not create that actual extent. A selected BoundedModelUseStructure, when it changes interpretation, is named in the receiving assertion or use. Only a genuinely structure-dependent relation species may require that structure as an identity-bearing participant, under its own direct pattern and stronger obtaining and identity law.

For a performed occurrence, this alignment lets the reader trace one Work individual admitted under U.Work through exact enactsMethod and performedUnderAssignment relations to the U.Method it enacts and the exact U.RoleAssignment under which its admitted holder system performed it; a separate assertion may cite the U.MethodDescription used to identify or constrain that method. It does not turn the assignment, role taxonomy, reference scheme, method description, capability fit, plan, or evidence into the performer or the work itself.

#Bounded specialization scouting and CheckpointReturn

When one human-plus-AI pair faces a new task family or candidate solution family, the governed work system may temporarily compose four distinct local roles inside the same dyad: a human-held OutcomeCriterionHolderRole, an AIScoutRole, an AISpecialistProbeRole, and a human-held CommitAuthorityRole. The payoff of the dyad is faster admissible specialization of the next work-family use, not disappearance of the human decision step.

For this bounded dyadic work question, the pair declares one outcome criterion first, enumerates heterogeneous candidate approaches that may satisfy that target, spends a bounded scouting budget or probing budget before any committed approach is chosen, and returns one CheckpointReturn that compares the tested approaches rather than silently treating one successful probe as a committed rollout. A.15 governs this dyadic alignment use and local role split only; it does not restate the checkpoint-record semantics of C.24 or the budget and guard enforcement of E.16.

Every CheckpointReturn carries:

• the declared outcome criterion and current TaskFamily
• the candidate approaches actually tested
• the evidence observed on each tested approach, including progress toward the named work-measure threshold and important failure signals
• the budget already burned and the residual budget still available
• the recommended next work-family use or reliance use: continue probing, commit to planned work, narrow the method or claim, apply the direct governing pattern for a non-A.15 claim, or stop
• the commit trigger named by value that would justify leaving the bounded probe

The return is candidate-approach evidence, burned and residual budget amounts, observed result, and commit-trigger condition. It is not the selected method, U.WorkPlan, an actual Work occurrence admitted under U.Work, an execution-evidence relation, an evidence-provenance relation, or a rollout decision. Those claims need the project-side FPF kind and reference named by value before committed rollout.

Low-human-overlap approaches remain admissible here only while they stay tied to the declared outcome criterion, budget limits, and evidence relation or evidence-provenance relation by value.

#Boundary to A.15.4 Work-Relevant Appearance-Based Reliance Repair

Use A.15.4 when an encountered episteme, episteme publication, display, credential view, generated explanation, copied statement, provenance mark, dashboard tile, schema wording, API wording, or composed source-relation chain is being used by appearance for a work claim, reliance claim, role-assignment currentness claim, role-state currentness claim, source-currentness claim, approval, authorization, gate passage, evidence, engineering justification, release reliance, or a claim about an actual Work occurrence.

A.15 itself keeps the kernel separation: U.Role, holder, role-taxonomy episteme, effective reference scheme, U.Method, U.MethodDescription, U.WorkPlan, U.Work as the admitted kind, one actual dated Work occurrence, any separate episteme about it, and the U.RoleAssignment chain between them. The appearance-based reliance repair recovers the project-side FPF kind and reference named by value before the reliance appearance can carry the work claim, reliance claim, or effect claim being made; that repair belongs to A.15.4 unless a direct governing pattern is already recoverable.

A principle scheme, functional diagram, scenario, screen, or explanation that makes an E.18.1 P2W carry-through structure recoverable may help the team plan work or find the needed source.

#Method-Work Unfolding Linkage

Use MethodWorkUnfoldingLinkage@Context only when a constraint-governed unfolding structure depends on a method and work relation that must stay inspectable across A.3 and A.15-family records. The linkage is a dependent relation record owned by this role-method-work alignment family; it is not a root U-kind, not a method, not work, not work authorization, and not evidence or gate passage.

MethodWorkUnfoldingLinkage@Context:
  kind: dependent relation/linkage record under A.15 and adjacent method, evidence, assurance, and gate governing patterns
  unfoldingStructureRef:
  methodRef?:
  methodRelationStructureRef?:
  methodDescriptionRefs[]:
  applicableRoleRefs[]:
  capabilityFitConditionRefs[]:
  transformationKindRefs[]:
  workPlanRefs[]:
  workEntryReadinessRefs[]:
  performedWorkRefs[]:
  evidenceRefs[]:
  assuranceRefs[]:
  gateRefs[]:
  stopOrReturnCondition:

capabilityFitConditionRefs[] points to A.2.2 capability-fit conditions for the method or work use. It is not a vague ability bucket, not a q-bundle by name, and not a measured characteristic unless [C.25](/generated/patterns/C.25), [C.16](/generated/patterns/C.16), or a characteristic or evaluation pattern is current.

When a CGUS, P2W, P2S, improvement-loop, or transformation-flow slice cites methodWorkLinkageRef?, the ref means only that this method and work relation needs to remain visible while the direct claims still keep their own authority. If a single direct claim is current, use its direct owner instead: U.Method or U.MethodDescription under A.3, work planning under [A.15.2](/generated/patterns/A.15.2), work-entry readiness under [A.15.5](/generated/patterns/A.15.5), an actual dated Work occurrence under [A.15.1](/generated/patterns/A.15.1), evidence under [A.10](/generated/patterns/A.10), assurance under [B.3](/generated/patterns/B.3), and gate under [A.20](/generated/patterns/A.20) or [A.21](/generated/patterns/A.21).

#Boundary to A.15.5 Work-Entry Readiness

Use A.15.5 when the current question is whether intended work is ready enough to enter a work boundary. A.15 keeps the role-method-work separation; A.15.5 carries WorkEntryReadiness@Context, FullKitCondition, commitment disposition, resource-readiness refs, WIP or flow-policy refs, planned-baseline refs, and launch-gate refs when they are current.

Readiness is not performed work, not evidence sufficiency, and not gate passage by itself. A readiness-looking briefing, dashboard, source bundle, or P2W record may cue A.15.5, but the readiness relation is admitted only when the target work plan or plan item, missing inputs, preparation work if performed, planned baseline, and stop or degraded-use condition can be named.

#Archetypal Grounding

The role-method-work alignment applies whenever the question under repair is holder-in-role, method description, intended plan, or performed work. Physical engineering, knowledge work, and socio-technical cases can all use the same distinction without turning A.15 into a universal process ontology.

Key takeaway from grounding: The welding and peer-review cases share one enactment alignment without sharing a domain ontology. Each has a holder U.System, a role interpreted by an exact role-taxonomy episteme and effective reference scheme, a four-participant U.RoleAssignment, a run-independent U.Method, a separate U.MethodDescription, a holder capability when reliance on it is current, and a dated Work occurrence admitted under U.Work. A selected model-use structure appears only in the receiving interpretation use that needs it. This is enough to compare the alignment while preserving different local structures; any classification beyond U.Work remains with its direct owner.

#Briefing guides orientation, not execution

Source set. A release team has one deployment method description, one current work plan, one approval or decision record when required, and the evidence records and evidence relations used to decide whether the rollout may proceed. A short rollout briefing is prepared for the daily stand-up.

Briefing slice. Status briefing only: rollback procedure appears verified in the current source bundle. Execution remains tied to the deployment method, work plan, required approval or decision record, and evidence relation.

This briefing may orient the team and cue attention. If the team wants to execute from the briefing alone, use A.15.4 or the evidence, gate, decision, or assurance pattern governing the claim to recover the missing project-side kind and reference. Inside A.15, keep only the role, method, plan, and work-occurrence separation.

#P2W principle-scheme publication guides planning, not occurrence

Source set. A team has a principle scheme that shows an E.18.1 P2W carry-through structure for a fabrication task: signature or principle episteme, method-family selection, selected method, U.WorkPlan, an actual Work occurrence admitted under U.Work, a separate work-result record, and result measurement.

Published slice. For this batch family, method M-2 is selected from the declared method family; prepare work plan WP-17 before any actual Work occurrence exists.

This publication may guide method inspection and work-planning preparation under A.15. A conforming use keeps selected method, U.WorkPlan, actual dated Work occurrence, separate assertion or record about it, work-result record, and result measurement distinct. If the publication is used for evidence, provenance, engineering justification, gate or constraint decision, physical medium, screen, export, OCR behavior, or publication-use, apply the governing pattern for that claim being made. If no project-side kind and reference named by value exists, create only an A.15.4 repair request, decision-request record for the next decision, prospective work-plan entry, or explicit missing-source-relation note.

#Scenario guides method selection, not performed work

Source set. A method-selection scenario says that material X is below threshold T, resource window W is available, and the fabrication cell is under setup condition S. The scenario is admitted source material, or an episteme publication exposing that source material, for choosing between method families.

Published slice. Under scenario S, method family MF-2 is admissible for planning; choose the selected method and prepare the work plan before execution.

The scenario can guide method-family selection and work-planning preparation. Once the team selects a method or prepares a plan, state that project choice or plan through its governed episteme. If an actual Work occurrence is later claimed, ground that world-side individual independently under A.15.1; a separately governed assertion or performed-work record may designate it but does not become the occurrence. If the scenario is used for evidence, gate, or engineering-justification reliance, first recover the project evidence relation, gate or constraint decision, or engineering-justification record named by value under A.10, A.20, A.21, or B.3; otherwise record only an A.15.4 repair request, decision-request record, prospective work-plan entry, or missing-source-relation note.

#Bias-Annotation

Lenses tested: Gov, Arch, Onto and Epist, Prag, Did. Scope: Universal for role-method-work enactment alignment across engineering, operational, and knowledge-work settings.

Bias risks and mitigations:

• Governance bias (Gov): teams may over-treat role labels or approval displays as enough evidence that work happened. Mitigation: keep U.RoleAssignment, U.MethodDescription, U.WorkPlan, U.Work as the admitted kind, actual Work occurrences, and epistemes about them distinct; state performed values and resource use only through obtaining relations involving the Work occurrence.
• Architectural bias (Arch): modelers may pull roles, capability instances, fit predicates, or capability support records into structural part hierarchies because those diagrams are already present. Mitigation: preserve the role as a value interpreted through an exact role taxonomy and effective scheme, U.Capability as the A.2.2 admitted capability instance, capability statements and currentness assessments as separately governed support relations, capability-fit as a separate checking or admission condition over that instance, and all of them outside structural part decomposition.
• Epistemic bias (Onto and Epist): a documented recipe or schedule can be mistaken for proof of execution. Mitigation: require the traceability chain from the actual Work occurrence through U.RoleAssignment and U.Method, and keep the U.MethodDescription and performed-work record as separate epistemes.
• Pragmatic bias (Prag): teams may keep using one overloaded "process" word because it feels faster. Mitigation: resolve "workflow", "schedule", and "what happened" wording through U.Method, U.MethodDescription, U.WorkPlan, the U.Work kind when kind-level classification is current, or one exact Work individual admitted under it.
• Didactic bias (Did): the chef analogy can make the pattern seem intuitive while hiding the need for explicit model links. Mitigation: pair the analogy with the canonical relations and checklist.

#Conformance Checklist

To preserve role-method-work modeling, check the following predicates.

#Common Anti-Patterns and How to Avoid Them

• Role-as-part. Do not place U.Role, U.Capability, capability-support records or relations, or capability-fit predicates inside structural partOf decomposition; keep role interpretation under its role taxonomy and effective scheme, capability as the A.2.2 admitted capability instance, support records or relations under their own governing patterns, and fit predicates as admission checks.
• Recipe-as-evidence. A U.MethodDescription or SOP may identify or constrain a method; a separate assertion or performed-work record may designate a dated Work occurrence, but the record is not the occurrence and cannot substitute for its world-side basis.
• Plan-as-performed-work. Do not let schedules, calendars, or intended assignments stand in for performed execution; use U.WorkPlan for intent, identify the actual Work occurrence independently under U.Work, and state its performed values through obtaining relations.
• Capability-as-work. Do not treat possession of a capability instance, a statement about it, or a passing fit predicate as if the task has already been performed; capability enables execution under conditions but is not execution.
• Approval collapse. Keep approval or authorization speech acts distinct from the operational steps they permit. When an approval is itself performed work, identify one separate Work individual admitted under U.Work and recover the exact speech-act or instituted-effect relation independently; the approval occurrence is not the later operational occurrence.
• Process soup. Do not leave "process", "workflow", or "activity" uninterpreted in FPF-governed passages; resolve the wording cue to U.Method, U.MethodDescription, U.WorkPlan, the U.Work kind, or one Work individual admitted under it.
• Briefing-as-execution-cue. A lighter review note, rollout summary, or redacted operations note may orient work; use A.15.4 appearance-based reliance repair or the direct governing pattern for that reliance before relying on it for execution, approval, gate, evidence, or plan claims.
• P2W publication as work occurrence. A principle scheme, functional diagram, scenario, screen, or explanation may guide selected method or work-planning uses named by value; recover the project-side FPF kind and reference named by value for any selected-method, work-plan, work-occurrence, result, evidence, gate, or engineering-justification claim, and keep the E.18.1 carry-through structure separate from those typed values.
• Reliance appearance as work-relevance cue. A dashboard tile, credential display, copied approval, generated explanation, provenance label, command-like cue, or composed source-relation chain is only a reliance appearance until A.15.4 recovers the project-side kind and reference named by value required for the work or reliance claim under repair.

#Consequences

#Rationale

This pattern solves a problem that has plagued systems modeling for decades: the conflation of what a system is with what it does. Its rigor is not arbitrary but is grounded in several key intellectual traditions.

• Ontology Engineering: The pattern is a direct application of best practices from foundational ontologies (like UFO), which have long insisted on the distinction between endurants (objects like a U.System) and perdurants (events and Work individuals admitted under U.Work), and between intrinsic properties and relational roles. FPF makes these powerful distinctions accessible to practicing engineers.
• Process-theory source tradition: Formalisms like the Pi-calculus or Petri Nets model dynamic interactions under terms often translated as processes. A.15 does not import process as a new FPF object; it maps the useful local use to U.Method, U.MethodDescription, U.WorkPlan, U.Work as the admitted kind, one actual dated Work occurrence, or a separate episteme about it. FPF adds the exact holder and four-participant role assignment, holder U.Capability instance when capability reliance is current, any separate capability statement or currentness assessment used for that reliance, any separate capability-fit condition over that capability instance when work admission is current, enacted U.Method, and separate U.MethodDescription that make the occurrence inspectable.
• Pragmatism and Practice: The framework is deeply pragmatic. The distinctions it makes between a MethodDescription, a capability instance, and a Work individual admitted under U.Work are precisely the ones that matter in project management, compliance, and debugging. When a failure occurs, a manager needs to know whether the recipe was wrong, the holder lacked the required capability, or this particular Work occurrence departed from the method. This framework provides the vocabulary to ask and answer that question precisely.

By creating this clean, stratified alignment for enactment, FPF provides a stable and scalable foundation for downstream resource accounting, decision, constraint, gate, evidence, assurance, ethics, and transformation patterns without letting any one of those neighboring claims collapse into A.15.

#SoTA-Echoing: Adopted and Adapted Invariants and Rejected Shortcuts

SoTA alignment rule. Read each row here as source idea -> local FPF invariant -> practical local test -> popular shortcut rejected. A source citation governs nothing by reputation; it counts only when the cited idea is translated into the Solution, conformance checks, boundary rules, worked slices, and Relations of this pattern.

Claim 1. Best-known current workflow, digital-thread, and service-operations source traditions keep recipe, plan, and execution separate.

Practice source, local alignment, and adoption decision. Contemporary process-modeling source traditions, service operations, and auditability practice after 2015 separate procedure, schedule, and executed occurrence because otherwise paper compliance becomes indistinguishable from completed work. In the manufacturing and peer-review slices above, this means a procedure or calendar never counts as the weld or the review itself. This pattern adopts that separation, adapts it through U.Method, U.MethodDescription, U.WorkPlan, U.Work as the admitted kind, actual Work individuals admitted under it, and separate epistemes about them, and rejects the shortcut where one undifferentiated "process" label carries all meanings.

Claim 2. Best-known current accountability practice keeps the exact holder and assignment explicit rather than attributing work to a role label or a document.

Practice source, local alignment, and adoption decision. Contemporary service delivery, incident practice, and role-accountability practice distinguish accountable assignee, governing procedure, and performed-work record because after-the-fact review depends on knowing who acted, under what role, and under which method. In the slices above, that is why the welding robot or peer-review assignee acts under U.RoleAssignment rather than the role or guideline acting on its own. This pattern adopts explicit holder attribution through U.RoleAssignment, adapts it to exact role-taxonomy and reference-scheme semantics, and rejects anonymous work logs and role-as-part modeling.

Claim 3. Best-known current approval and execution practice treats a communicative gate act and the operational act it permits as distinct Work occurrences with distinct obtaining effect relations, not as two label-defined U.Work subkinds.

Practice source, local alignment, and adoption decision. Contemporary release, compliance, and safety-critical practice separates approval, authorization, and review acts from the operational steps they permit because authority change and world change are not the same event. In the examples above, an approval Work occurrence and a deployment or welding Work occurrence are distinct individuals admitted under the same U.Work kind and connected to different exact effect relations. This pattern adopts that split, adapts it through separately grounded Work individuals and their direct relations, and rejects both the collapse of approval into the permitted operation and the invention of communicative versus operational Work subkinds by label.

Local claim. The FPF-governed SoTA claim for this pattern is practical and narrow: role-method-work enactment remains reviewable only when role, method, plan, and work stay distinct enough that audits can tell whether the problem was in the assignment, the recipe, the schedule, the capability, or the performed occurrence itself.

Claim 4. Best-known current agentic work practice treats fast bounded specialization as a checkpointed scout and probe discipline rather than as a naked winner claim.

Practice source, local alignment, and adoption decision. Contemporary agentic tool-use, adaptive method-selection, and human-in-the-loop work-control practice separates bounded exploration from committed rollout because a successful probe is not yet an admissible committed approach. In the working moment above, that is why the pair returns one CheckpointReturn with candidate approaches, evidence, burned and residual budget, and a commit trigger rather than only a winner label. This pattern adopts checkpointed scout and probe discipline, adapts it through the dyad-local roles and CheckpointReturn, and rejects the shortcut where an early probe silently becomes a committed rollout.

For visible credential, provenance, dashboard, explanation, or composed-source cases that need project-side FPF kind and reference named by value before work or reliance, use A.15.4. The A.15 family carries only the role, method, plan, and work portion of the case.

The nearest recovery loci are the manufacturing, peer-review, rollout briefing, CC-A15-7, CC-A15-10, CC-A15-12, and the boundary to A.15.4. If a SoTA row cannot be recovered through those local checks, do not let the source citation stand in for the local A.15 rule.

#Relations

• Architecture method/work boundary: C.32.P2S and C.32.PAD may cite method descriptions, pattern-use refs, responsibility-bearing role assignments, readiness exits, and expected structure effects as architecturing or decision-output duties. C.32.ADR may publish those refs. A.15 still governs method, method description, work plan, work-entry readiness, performed work, and performed-work attribution claims.

• Directly applies: A.7 Strict Distinction for the role, method, method-description, plan, and work split.

• Builds upon: A.2 for U.Role, A.2.1 for U.RoleAssignment, A.2.2 for U.Capability, A.2.5 for role-state admission, A.2.7 for role relation structure, A.6.5 for slot-relation discipline used by assignment and relation declarations, A.3.1 for U.Method, A.3.2 for U.MethodDescription, A.3.3 for U.Dynamics, A.3.4 for U.Transformation, A.15.1 for U.Work, A.15.2 for U.WorkPlan, A.15.3 for slot-filling plan items, A.15.5 for work-entry readiness, and F.6 as the direct owner of performedUnderAssignment and the derived actualPerformerSystem(W, RA) cue.

• Coordinates with: A.15.4 for work-relevant appearance-based reliance repair; A.15.5 for full-kit preparation and work-entry readiness; E.10 and E.10.ARCH for wording recovery around process, workflow, activity, schedule, algorithm, solver, and procedure wording; A.6, A.6.B, and A.6.C for mixed boundary, policy, API, schema, agreement-like, or promise wording; A.10 for evidence, currentness, and provenance; B.3 for assurance claims; A.21 for OperationalGate(profile), GateDecision, and DecisionLogRef; A.20 for ConstraintValidity status or witness; C.28 for causal-use admissibility; C.29 for mathematical-lens use; E.18.1 for P2W carry-through; C.32.P2S for architecturing flow refs to method, work plan, readiness, and performed work; and E.17.EFP for generated-explanation faithfulness or source-finding.

• Used by: patterns that need to keep systems or acting holons with role assignments, method descriptions, work plans, work occurrences, result records, and appearance-based reliance repairs distinct. A.15 is not a generic process ontology, workflow engine, evidence graph, gate pattern, or publication pattern.

#Coordinated-work evidence and distributed-state relation note

Use A.15 first when the claim is about who acts, by which method, under which role, under which work plan, producing which work result. Coordinated work, routine skill, team alignment, tacit knowledge, and role-method fit are not quantum-like by default.

Application choices:

1. Name the role, method, and work result before naming any distributed state.
2. State which exact Work occurrences admitted under U.Work and which separate C.2.1 assertions about that work, work traces, work-event records, observations, reports, or metrics make the coordination visible.
3. Ask whether role-method-work alignment alone explains the case. If yes, stay in A.15.
4. If no participant statement, local component report, single evidence record, dashboard, or exported representation carries the inferred state faithfully enough for the intended state use, add a C.26.2 low-recoverability distributed-state reading.
5. State the weakest evidence-bound state-reading claim, time window, rival explanations, and export loss.
6. Carry evidence use through A.10 and assurance claims through B.3 when the reading will guide work, reliance, audit, readiness, release, or compliance.

Add a C.26.2 low-recoverability distributed-state reading only when coordinated work is being used as evidence for a state that no participant statement, local component report, single evidence record, dashboard, or exported representation carries faithfully enough for the intended state use. In C.26.2 terms, the reading is a minimal evidence-bound U.Episteme claim under carriers, window, rivals, and export limits; it is not a group mind, not performed work, not evidence sufficiency, and not assurance by itself. That evidence-bound reading states:

Useful outputs:

• an A.15 work-alignment claim when work roles explain the case;
• a C.26.2 low-recoverability distributed-state reading when coordination evidence survives ordinary rivals;
• an A.10 evidence relation or B.3 assurance claim relation when the distributed-state reading will be used as evidence or assurance for a work claim or reliance claim;
• no distributed-state reading when evidence sources, rivals, or time window cannot be named.

#C.29 mathematical-lens use relation

If a mathematical lens helps select a method, compare method families, shape a work plan, or diagnose work, use C.29 only for the fit of that mathematical diagnostic or method-selection reason. The next concrete object remains under the A.15 family: ChoiceResult or local choice record when a choice is made, selected method or method-family selection when the method-governance claim is being made, U.WorkPlan for a plan, an actual Work occurrence admitted under U.Work for execution, a separate work-result record for a result claim, and an A.15.4 appearance-based reliance repair reference when a reliance appearance is being used as reason for work or reliance before the governing pattern slot or relation is named. A mathematical lens may explain why a diagnostic distinction is useful; it does not make a plan into performed work or a method explanation into execution evidence.

#P2W Work-Family Split

When a P2W use under E.18.1 produces a WorkPlanning or work-entry readiness relation, this family carries the split among selected method, U.WorkPlan, SlotFillingsPlanItem, WorkEntryReadiness@Context, an actual Work occurrence admitted under U.Work, and separate result-related records. A P2W principle scheme, functional diagram, or scenario may guide method inspection and work-planning preparation only after the current work-family object is named.

WorkPlanning may place evidence-reference hooks and source-currentness requests for the governing pattern that carries the relation under repair. A.15.5 may cite WorkPlan and SlotFillingsPlanItem baselines when readiness is the current relation. If the relation under repair is evidence, gate passage, launch-value finalization, performed work, result measurement, assurance, or refresh, name that relation before relying on the work-planning or readiness record.

#P2W Performed-Work Relation

When E.18.1 reaches performed work, this family keeps U.Work as the admitted kind and identifies one exact dated Work occurrence under it. WorkEnactment is not a second kind and should not be used as a pseudo-object between a plan and the occurrence.

A performed-work record is a separate U.Episteme that may cite a U.WorkPlan, planned baseline, and the exact Work occurrence. It may state actual launch bindings, performed values, substitutions, variance, telemetry, outputs, outcome claims, and result-record references only by citing their independently obtaining relations; none is stored in or constituted by the Work occurrence. Comparator, transport, PrincipleFrame, U.Signature(profile=FormalSubstrate), evidence, assurance, and gate relations remain separately governed.

#P2W Integration As Role Enactability

When E.18.1 uses integration wording to mean role enactability under interface constraints, this family carries the role, method, plan, and performed-work part of the claim. Name the selected role, U.RoleAssignment when the role-assignment claim is being made, method or method description, relevant U.WorkPlan or actual Work occurrence admitted under U.Work, and the interface constraints governed by the architecture or module-interface pattern.

If the same phrase also raises connected artifacts, telemetry, acceptance records, diagrams, module-interface claims, selected-structure claims, checks, gates, evidence, or provenance, split those relations before relying on the integration wording.

#Lowering, Repair, and Refresh Conditions

Lower an A.15 claim when the role, holder, role-taxonomy episteme, effective reference scheme, method, method description, work plan, work-entry readiness relation, performed work occurrence, or capability check cannot be named at the granularity required by the next work-family use. A weaker but admissible result is a separation note, missing-source-relation note, A.15.4 repair request, decision-request record for the next decision, prospective work-plan entry, or A.15.5 readiness-gap note.

Repair the local alignment frame when a subsequent source shows that the role assignment, method description, work-plan baseline, performed-work occurrence, capability threshold, role-state currentness record, or source-currentness window was wrong for the claimed use. Repair only the changed relation: do not rewrite the method when only the work plan changed, do not rewrite the work occurrence when only the evidence relation changed, and do not treat an A.15.4 repair request as carrying a non-A.15 claim.

Refresh the A.15 use before relying on it under a new role taxonomy, effective reference scheme, selected model-use structure, role assignment, method family, work plan, execution window, result measurement, or evidence, assurance, gate, appearance-based reliance repair, or mathematical-lens relation. If the issue under repair after refresh is no longer role-method-work alignment, use the governing pattern for that relation and keep only the remaining A.15 separation here.

#A.15:End

#U.Work

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

At a glance. Use U.Work as the admitted kind when the current claim concerns one performed Work individual: a world-side dated occurrence performed by one or more admitted holder U.Systems under exact obtaining U.RoleAssignments. The systems perform the work; the assignments are the separately obtaining role-holding relations under which the attribution is valid. The occurrence has an actual temporal extent, enacts an exact method, and is executed within an exact containing system. State a binding, resource-use fact, or direct work-to-referent relation only when it actually obtains and the receiving use needs it; an assertion, description, log, or record about the occurrence is a separate U.Episteme and does not store fields in the occurrence. When the reader asks what the work returned, changed, produced, transferred, or caused someone to accept, use the concrete three-question route in §4.6 instead of adding an output or outcome field to Work.

Use this when. Use this pattern when a plan, method description, schedule, log, telemetry stream, dashboard, approval-looking cue, publication face, result statement, or evidence-provenance relation is being treated as if it were performed work. U.Work is the admitted kind; one Work individual is the world-side occurrence. A separate assertion or description episteme may designate that occurrence and its obtaining relations, while surrounding records may constrain, evidence, schedule, publish, or judge it; none becomes the occurrence by being published.

First useful object. One independently identified world-side dated Work occurrence admitted under U.Work. When the receiving use needs an assertion or description, keep that object as a separate U.Episteme: let it designate the occurrence and state the admitted holder U.System that actually performed it, the exact obtaining U.RoleAssignment under which that system performed it, and, when explicit attribution identity is consumed, the F.6 attribution relation linking the Work occurrence to that assignment. State actual enactsMethod -> U.Method, temporal extent, and executedWithin -> U.System. Add a direct work-to-referent relation, binding, or resource-use relation only when it actually obtains and the receiving claim uses it. If the next sentence reports a result, change, production, delivery, or judgment, use the matching §4.6 row; do not make it a Work field.

First-use checks.

1. Name the candidate occurrence and the work-facing claim that depends on it.
2. Recover every admitted U.System that actually performed the occurrence and the exact obtaining U.RoleAssignment under which each system performed it; then recover the enacted U.Method, temporal extent, and accountable or containing U.System. Add only the concrete bindings, performed resource-use facts, and direct work-to-referent relations that actually obtain and matter to the receiving use. Route any claimed result, change, production, delivery, evidence use, or judgment through the one matching §4.6 row.
3. Decide whether the encountered record, trace, item, or display designates a Work individual admitted under U.Work, only a plan (A.15.2), only a method (A.3.1), only a method description (A.3.2), only evidence for work (A.10), only a publication-use relation (E.17), only a declarative representation (C.2.P.DR or the direct representation pattern), or an A.15.4 appearance-based reliance repair case.
4. For composite, repeated, interrupted, or overlapping occurrences, declare each work-part relation and the naming threshold. Before using totals, recover the exact B.1.4 temporal aggregation or B.1.6 work-resource aggregation and its policy. Do not name a work part when a temporal relation, evidence slice, telemetry segment, or missing-source-relation note is the actual object needed.
5. If the required occurrence references cannot be recovered, lower the claim to a missing-source-relation note, work-evidence note, plan note, publication-use note, declarative-representation note, or A.15.4 repair request; do not backdate work.

Ordinary use. For a simple occurrence, one readable assertion naming the actual performer system, the covering assignment under which it performed, enacted method, temporal extent, and containing system is enough. Add a binding, used resource, or work-to-referent fact only when the assertion relies on that obtaining relation.

Work-versus-transformation probe. Use the coarsest branch that the current facts support.

• Change without Work: LunarTideRise-2026-07-27 may be identified under A.3.4 as a transformation of the exact water body over the stated interval. Without an independently admitted performer U.System, its covering U.RoleAssignment, an enacted U.Method, and F.6 work attribution, it is not a Work occurrence. A causal explanation of the tide supplies none of those agency facts.
• Self-directed Work: in the rehabilitation case, the current model admits MotorControlRightArmSystem-7 : U.System and Person-7 : U.System; A.14 ComponentOf(MotorControlRightArmSystem-7, Person-7) and ComponentOf(LeftArm-7, Person-7) obtain, so the mover and the affected limb are distinct parts of one person. MotorControlRightArmSystem-7 performs LeftArmStretchWork-7 from 2026-07-27T07:30:00+03:00 to 2026-07-27T07:35:00+03:00 under SelfCarePerformerAssignment-7; F.6 performedUnderAssignment obtains, the Work enacts AssistedLeftArmStretchMethod-E1, and executedWithin -> Person-7 obtains. Clinic relation specification ClinicRehabRelations@Clinic-E1 declares RehabWorkStretchesLimb@Clinic-E1(work, limb, interval), and the case facts make it obtain for that Work, LeftArm-7, and the five-minute interval. Separately, A.6.1 application AssistedStretchApplication-7 binds its declared AffectedLimbArgument to LeftArm-7. The first fact relates the Work to the limb; the second fills an operation argument. Neither is a primitive self-relation, and this case-specific decomposition is not a required anatomy for every self-directed action.

These branches test admitted facts, not human resemblance. A non-human or molecular-scale system can perform Work when its own system admission, covering assignment, enacted method, extent, containing system, and attribution obtain; unfamiliar agency is not a reason to reject it.

Reliance-bearing use. Add only the exact neighboring claims on which cost, quality, audit, evidence, conformance, gate, release, measurement, model use, or aggregation currently depends; do not turn them into fields of the work occurrence.

Stop condition. Stop once the occurrence is either recoverable as one Work individual admitted under U.Work at the needed granularity or lowered to a neighboring relation that no longer claims performed work.

What goes wrong if missed. Teams count plans, method descriptions, approval-looking cues, dashboards, telemetry, or evidence records as if work already happened, then attach cost, responsibility, quality, or result claims to the wrong EntityOfConcern.

What this buys. One dated occurrence identity whose actual performer systems, covering assignments, enacted method, temporal extent, and containing system remain inspectable, together with any actually obtaining work-to-referent, binding, and resource-use relations used by the claim. A practitioner can then report a result or consequence through the concrete §4.6 branch without turning it into Work identity.

Not this pattern when. Not this pattern when the current claim is only a method (A.3.1), only a method description (A.3.2), only a plan or schedule (A.15.2), only declaration-local SlotFillingsPlanItem content inside an A.15.3-governed WorkPlan, only work-entry readiness or full-kit preparation before work entry (A.15.5), only a visible cue that needs A.15.4 appearance-based reliance repair before reliance, only evidence or assurance (A.10 or B.3), only publication-use behavior (E.17), or only a declarative representation overread as a work-control or method claim (C.2.P.DR or the direct representation pattern).

#Problem Frame

After we have separated who is assigned (via U.RoleAssignment), what capability is being relied on (via U.Capability), how in principle the work is done (the exact U.Method), and which claim-bearing episteme, if one is selected, describes that method (U.MethodDescription), we still need a precise concept for what happened as performed work in real time and space.

Every Work individual has actual performer-system, covering-assignment, enacted-method, temporal, and containing-system facts. It stands in a direct work-to-referent, binding, or resource-use relation only when that relation obtains world-side; none is a field stored in the occurrence. A separate assertion or description may designate that individual and state the relations, but the episteme neither creates the relations nor becomes the Work occurrence.

#Problem (what breaks without a clean notion of Work)

1. Plan and occurrence confusion. Schedules and diagrams get mistaken for performed work, so audits and KPIs attach to plans or representations instead of dated occurrences.
2. Method-description and work conflation. A method description, code artifact, or SOP is reported as if it were performed work; conversely, logs are treated as recipes.
3. Who and when leakage. People and calendars are baked into method descriptions; reuse and staffing agility collapse.
4. Resource dishonesty. Energy, money, and tool wear are represented as fields or booked to methods or roles instead of being stated through separately obtaining resource-use relations involving exact Work individuals; costing and sustainability measures drift.
5. Mereology muddle. Teams hand-wave over work parts, retries, overlaps, or long-running episodes; roll-ups double-count or miss work.

#Forces (what the definition must balance)

#Solution — admit accountable dated Work occurrences under U.Work

#Definition and occurrence identity

U.Work is the admitted U-kind for dated 4D occurrence holons. One Work individual is one independently identified world-side dated performed occurrence with its own governed temporal extent. The actual performer is an admitted U.System. For every performer, recover the exact obtaining U.RoleAssignment whose HolderSystemSlot resolves to that system, whose role interpretation is current, and whose occurrence covers the work or the exact attributed work part. The system acts; the assignment is the world-side relation under which the attribution holds, and it neither acts nor enacts a method.

The canonical F.6 relation performedUnderAssignment(W, RA) attributes one exact Work occurrence to one exact assignment occurrence. For an obtaining attribution, its actual-performer projection is S = RA.HolderSystemSlot; the relation obtains only when admitted system S actually performed W under RA and RA covers the attributed extent. In practitioner prose name both objects: S performed W under RA. The legacy spelling performedBy(W, RA) is a deprecated compatibility alias only; do not author new claims with it, and never say that RA performed W.