#Cluster A.V - Constitutional Principles of the Kernel

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

#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 object, such as a diagram, dashboard, card, model output, PublicationUnit, carrier, 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

#Universal Core Principle (C‑1)

“A principle that works in only one world is local folklore; a first principle architects every world.”

#Problem Frame

FPF aspires to be an operating system for thought that engineers, biologists, economists, and AI agents can all use without translation layers. That promise rests on the universality of its core primitives (U.Types). History is littered with “upper ontologies” that proclaimed universality yet smuggled in the biases of a single discipline; once deployed beyond their birthplace, they cracked or ballooned. Rule C‑1 turns “universal” from a marketing word into a measurable criterion: cross‑domain congruence.

#Problem

#Forces

#Solution — The Three‑Domain Falsification Test

Normative Rule (C‑1) A U.Type enters the kernel only if it is shown to play the same Role in at least three foundationally distinct domains.

Heterogeneity & QD‑triad guarantee (C‑1.QD). In addition to distinct domain‑families (choose from: Exact Sciences - Natural Sciences - Engineering & Technology - Formal Sciences - Social & Behavioural Sciences), the triad SHALL demonstrate quality diversity: (a) Hetero‑test. Each projection adds at least one non‑trivial DescriptorMap signal or Bridge path not subsumed by the other two (no aliasing by mere renaming). (b) QD evidence. Publish Creativity‑CHR / NQD‑CAL evidence for the triad: Diversity_P (set‑level) and its IlluminationSummary telemetry metric with ≥3 non‑empty cells and occupancyEntropy > 0 under the declared grid. (c) Policy disclosure. Declare the Context‑local QD_policy (binning/grid, kernel, time‑window) used to compute the telemetry metrics. (References: C.17 Diversity_P & illumination Summary as telemetry metric; C.18 U.DescriptorMap, U.IlluminationSummary.)

Implementation steps (Domain Families):

1. source domain‑families from the active F1‑Card (taxonomyRef/embeddingRef edition). The five coarse families {Exact, Natural & Life, Engineering & Tech, Formal, Social & Behavioural} are informative only; if used for pedagogy, publish an explicit mapping to the F1‑Card taxonomy. The triad gate is measured by MinInterFamilyDistance ≥ δ_family (per F1‑Card), not by labels alone.

2. Role‑Projection Records For each domain, author a short Role‑Projection tuple: {domain, indigenous term, Role, exemplar}. Example: {physics, "Free Energy", extremum driver, closed gas system}.

3. Congruence Check All three exemplars must satisfy the same abstract intent; superficial analogy is rejected.

4. Living Index Track the ratio

   $$ U\text{-Index}=\frac{\text{# kernel types lacking 3 projections}}{\text{# kernel types}} $$

   as a health signal; target ≤ 0.05 (not a bureaucratic gate).

Rule of thumb for busy managers: “One idea, three worlds. If you can’t point to the trio, park it in a Extention Pattern.”

#Archetypal Grounding (System / Episteme)

These juxtapositions give engineer‑managers an immediate sense of why each primitive is worth learning.

#Conformance Checklist

#Consequences

#Rationale

Deep research over the last decade shows structural homologies across domains:

• Free‑energy minimisation ↔ negative log‑likelihood ↔ Bayesian surprise (Friston 2023).
• Conservation laws in physics mirror budget balancing in economics (Rayo 2024).

By demanding three independent manifestations, FPF captures these convergences without privileging any single vocabulary. The principle operationalises Popperian falsifiability for universality: a concept that cannot survive a three‑domain cross‑examination is, by definition, not a first principle. This guards Pillars P‑1 (Cognitive Elegance) and P‑4 (Open‑Ended Kernel) simultaneously.

#Relations

#Known Uses

• Energy ↔ Budget ↔ Attention – Engineering teams reused U.Resource to reason about battery charge, project funds, and user‑attention minutes with one algebra, cutting integration effort by half (2024 pilot).
• Objective unification – An AI lab mapped loss functions, a bio‑lab mapped Darwinian fitness, and a factory mapped scrap‑rate all to U.Objective, enabling shared optimisation tooling.

These cases validated that the Three‑Domain Test is achievable in practice, not theoretical paperwork.

#Open Questions

1. Domain taxonomy stability – Should the five domain families be versioned as science evolves (e.g., quantum‑bio‑tech)?
2. Automated congruence checks – Can category‑theoretic tooling semi‑automate the functional‑role equivalence test?
3. Edge‑case hybrids – How are bio‑cyber‑physical chimera systems counted: a new domain or a composite projection?

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

#Carrier and source-currentness records

When an episteme composition, publication, compilation, dashboard, generated explanation, or assurance use substantively relies on source carriers, the evidence-provenance path SHALL keep a carrier/source-currentness record: carrier id or source reference, type, version or edition when relevant, date or relevance window, source conditions, 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 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 a carrier/source-currentness record 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 carrier/source-currentness records.

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 paths

Use this subsection when an authority-looking case is being used as evidence for a reliance claim. The A.10 evidence path is claim-bound: it evidences one named claim or effect for one named work move or reliance move, not "authority" in general. This subsection does not change the A.10 evidence-path 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 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 path is incomplete, A.10 reports evidence-path 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.

Broken-source 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, role-assignment source, status source, or boundary source. The A.10 result should name the missing source and blocked use rather than making the relying actor reconstruct a source they cannot issue or verify.

Repeated missing-source indicator. If the same visible carrier family repeatedly returns stale, contested, no-source, or no-currentness A.10 results, record a source-relation repair action: instrument the source, expose decision-source refs, add currentness checks and status checks, preserve claim-bound source links 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 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 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-path 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 refs, status, currentness, claim-bound source links, credential view, model documentation, data documentation, or provenance and attestation label.

Contestability and redress relation: when an evidence path or currentness path 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 or status source, freshness or revocation source, privacy-minimized evidence ref, safe interim disposition, and review or redress relation. A disputed display remains contested until the source-order or currentness question 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 path and evidence-use classification that A.15, A.6, B.3, A.21 gate-decision sources, A.20 constraint-validity sources, A.2.9 speech-act sources, A.2.8 commitment sources, A.15.1 work-occurrence sources, or another governingPatternRef or authoritySourceRef named by value may consume.

#Local evidence-use classifier and RelianceDisposition for source-looking evidence uses

Use this subsection when a visible source is being treated as evidence for a claim, act, work move, gate, release, review claim, assurance use, or problem-side P2W use. The first A.10 move 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 move: 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 source-looking carrier or display.

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 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 source looks official, quantitative, generated, credentialed, or safety-related.

Common wrong first classification: a visible source is approval, permission, safety, or readiness. First honest entry: recover the A.10 evidence 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 move 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 path or governing source relation changes.

For A.10 use, RelianceDisposition is a local disposition over the evidence 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, 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 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 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-path micro-examples:

What changes in practice: an evidence 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

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

#Consequences

#Rationale and SoTA alignment

• 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 carrier/source-currentness record 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-source entry as the source 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 source, not automatically the source 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-source recoverability, and claim-bound attribution as evidence-path invariants, adapts credential practice, provenance practice, attestation practice, model documentation, data documentation, register-backed status display, and generated-explanation practice as FPF source-side role-assignment values and carrier-relation inputs, 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 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 Graph & Proofs) where its current dependency-graph 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 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 old evidence-role or status-role 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 paths for those sources; 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 a carrier/source-currentness record;
• a release-context source register becomes a context-adapted carrier/source-currentness record 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 method-description source, 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 record or context-adapted carrier/source-currentness 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 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 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 (C‑5)

“Add only what you cannot subtract.”

#Context

The FPF kernel aspires to remain small enough to learn in a week yet broad enough to model engines, proofs and budgets alike. Unchecked growth of primitives—well‑known from earlier “enterprise ontologies”—bloats diagrams, stalls tooling and intimidates new adopters. C‑5 therefore demands minimal‑sufficiency: a new core concept enters the kernel only when all routes of composition, refinement or role‑projection fail to express it without semantic loss.

#Problem

Result: steep learning curves, fragile integrations, eroded trust in “first‑principles” promises.

#Forces

#Solution — Four‑Gate Minimal‑Sufficiency Protocol

A proposal to add a U.Type or core relation MUST clear all four gates before admission and survives under a Sunset Timer thereafter.

Sunset timer — provisional-type review A cleared type enters the kernel provisionally with a timer (default = 4 quarters). If usage count remains zero at expiry, the type faces Sunset Review: delete, demote to Extention Pattern, or renew with fresh evidence.

Manager’s mnemonic: “Compose, Unique, Functional, Crisp — or sunset.”

#Archetypal Grounding

#Conformance Checklist

#Consequences

#Rationale

Cognitive science shows working memory tops out around 4 ± 1 unfamiliar chunks (Cowan 2021). Combining that with Gate discipline keeps kernel size tractable (≈ 40 primitives). Software metrics from lean DSLs (Rust traits, Kubernetes CRDs) reveal that compositional modelling reduces change propagation cost by ~30 %. The Sunset Timer borrows from Kubernetes feature gate “alpha/beta/GA” progression model — proved effective at pruning half‑baked APIs.

#Relations

#Illustrative Uses (2022 – 2025)

• Robotics CAL 2023 – U.LiDARSensor rejected (Gate G‑1 passed via role composition), saving three schema migrations.
• Green‑Finance CAL 2024 – U.CarbonCredit admitted provisionally, but Sunset Review (usage = 0) demoted it to sector pattern, avoiding kernel noise.
• Neuro‑informatics 2025 – U.ProvenanceChain accepted; by Q3 its heavy reuse in three patterns lifted timer and marked it established.

#Open Questions

1. Hard size cap — should the kernel enforce an absolute limit (e.g., 64 live types) beyond which any new entry-selection effects retirement of an old one?
2. Semantic similarity tooling — can embedding models automate Gate G‑2 overlap detection reliably across domains?
3. Gate calibration — is default Sunset Timer (4 quarters) optimal for research‑oriented patterns with slower adoption and evidence accumulation?

#A.11:End

#External Transformer & Reflexive Split

#Intent & Context

The principle of causality is the bedrock of engineering and scientific reasoning: every change has a cause. In FPF, this translates to a strict architectural rule: no "self-magic." An action cannot happen without an actor. This pattern establishes the formal mechanism for modeling causality, ensuring that every transformation is attributed to an explicit, external agent.

This pattern operationalizes the Agent Externalization Principle (C-2). It builds directly upon:

• A.3 (Transformer Constitution): Which defines the core quartet of action: the Agent (who acts), the MethodDescription (the recipe), the Method (the capability), and the Work (the event).
• A.2 and A.2.1 (U.RoleAssignment): Provide the holder, role value, bounded-context, and current-window slots used to state the acting-side assignment.

The intent of this pattern is twofold:

1. To mandate that every transformation is modeled as an interaction between a distinct Agent (playing a TransformerRole) and a distinct Target across a defined Boundary.
2. To provide a rigorous pattern, the Reflexive Split, for modeling systems that appear to act upon themselves (e.g., self-calibration, self-repair) without violating the principle of external causality.

#Problem

Without a strict rule of agent externalization, models become ambiguous and untraceable, leading to critical failures in design and audit:

1. Causality Collapse ("Self-Magic"): Phrases like "the system configures itself" or "the document updates itself" create a causal black hole. It becomes impossible to answer the question, "What caused this change?" This makes debugging, root cause analysis, and assigning responsibility impossible.
2. Audit Dead-Ends: An auditor tracing a change finds that the system is its own justification. There is no external evidence, no log from an independent actor, and therefore, no way to verify the integrity of the transformation. This is a direct violation of Evidence Graph Referring (A.10).
3. Hidden Dependencies: In a "self-healing" system, the healing mechanism (the regulator) and the operational part (the regulated) are modeled as a single monolithic block. This hides the critical internal dependency between them. A failure in the regulator might go unnoticed until the entire system collapses, because its role was never made explicit.

#Forces

#A.12:4. Solution

The solution is a two-part architectural mandate: (1) all transformations must be modeled with an external agent, and (2) apparent self-transformation must be modeled using the Reflexive Split.

#The Principle of the External Transformer

Every transformation in FPF is a U.Work event that is the result of an Agent acting upon a Target.

• The acting-side assignment: the acting side is a U.RoleAssignment with holderRef naming a U.System or admitted acting holon, roleRef=TransformerRole@Context, and boundedContextRef naming the context. This is the causal/work side, not a compact holder-role shorthand.
• The Target: The target is the U.Holon being changed. This can be another U.System or the symbol carrier of a U.Episteme.
• The Boundary: The agent and the target are always separated by a U.Boundary and interact through a U.Interaction.

Crucial Rule: The holder of the Agent's U.RoleAssignment cannot be the same holon instance as the Target.

holder(Agent) ≠ Target

This simple inequality is the core of the externalization principle. It constitutionally forbids self-magic.

#Reflexivity vs cross‑reference (normative note)

FPF distinguishes reflexive transformation from episteme‑level reference. Reflexive cases (e.g., “self‑calibration”) MUST be modeled by the Reflexive Split (Regulator→Regulated) and remain within the world ReferencePlane. When a claim refers to another claim/episteme, model it with epistemeAbout(x,y) and set ReferencePlane(x)=episteme. Such references do not perform transformations and MUST NOT be used to bypass the external‑agent rule. Evaluation of chains of episteme‑about relations MUST remain acyclic within a single evaluation chain; otherwise, abstain and request a split or external evidence.

#The Reflexive Split Pattern

So, how do we model a system that does act on itself, like a self-calibrating sensor? We use the Reflexive Split. We recognize that the system is not a monolith; it contains at least two distinct functional parts.

The Procedure:

1. Identify the Roles: Decompose the system's function into two distinct roles: the part that regulates and the part that is regulated.
2. Model as Two Holons: Model these two parts as two distinct (though possibly tightly coupled) U.System holons, even if they share the same physical casing.
3. Define the Internal Boundary: Model the interface between them as an internal U.Boundary with a defined U.Interaction (e.g., a data bus, a mechanical linkage).
4. Assign the Transformer Role: The regulating part becomes the holder of the TransformerRole. The regulated part becomes the Target.

Now, the "self-action" is modeled as a standard, external transformation that just happens to occur inside the larger system's boundary. Causality is restored, and the model becomes auditable.

Didactic Note for Engineers & Managers: The "Two Hats" Analogy

Think of the Reflexive Split like a manager who needs to review their own work. To do it properly, they must metaphorically wear "two hats."

• Hat 1: The Doer. They perform the task.
• Hat 2: The Reviewer. They step back, put on their "reviewer hat," and inspect the work as if it were done by someone else.

The Reflexive Split formalizes this. The "Doer" is the Regulated subsystem. The "Reviewer" is the Regulator subsystem, which plays the TransformerRole. By modeling them as two separate entities, we make the internal quality control loop explicit and prevent the logical error of a system magically grading its own homework.

#Archetypal Grounding

The principle of external causality and the Reflexive Split pattern are universal. They apply equally to physical systems, epistemes, and socio-technical organizations.

Key takeaway from grounding: These examples demonstrate that there is no such thing as self-action in a well-formed model. Every action, even an internal one, can and must be decomposed into an external interaction between a distinct agent and a distinct target. This makes the causal chain explicit and auditable in all domains.

#Conformance Checklist

To enforce the principles of externalization and causal clarity, all FPF models must adhere to the following normative checks.

#Consequences

#Rationale

The principle of externalization is not an arbitrary rule imposed by FPF; it is a distillation of foundational concepts from multiple rigorous disciplines.

• Cybernetics & Control Theory: As Ashby's Law of Requisite Variety and modern control theory (e.g., Matni et al., 2024) demonstrate, regulation is fundamentally an interaction across a boundary between a controller and a plant. Conflating the two hides the causal structure and makes stability analysis impossible. The Reflexive Split is the FPF's implementation of this core cybernetic principle.
• Physics (Constructor Theory): As discussed in A.3, Constructor Theory recasts physics in terms of what transformations are possible. A transformation is always performed by a "constructor" (our Transformer) on a substrate. The theory does not contain "self-constructing" substrates. FPF's externalist stance is fully aligned with this physical worldview.
• Philosophy of Science (Objectivity): The scientific method is built on the principle of external observation and verification. A theory cannot validate itself; its predictions must be checked by an independent experiment. The No Self-Evidence rule (CC-A12.5) is the direct implementation of this principle in the FPF's assurance calculus.
• Software Engineering (Dependency Inversion): The dependency-inversion principle says that policy modules should not depend directly on implementation modules; both depend on abstractions. This is a form of externalization. It enforces clean separation and makes systems more modular and testable. The explicit U.Boundary in our pattern serves the same architectural purpose as a well-defined interface in software.

By mandating externalization, FPF is not adding bureaucratic overhead. It is enforcing a set of first principles that are demonstrably essential for building complex systems that are understandable, auditable, and trustworthy.

#Relations

• Directly Implements: C-2 Agent Externalization Principle.
• Builds Upon:
  • A.1 Holonic Foundation: Provides the U.System and U.Episteme holons that act as agents and targets.
  • A.2 Role Taxonomy: Provides the Contextual Role Assignment (U.RoleAssignment) mechanism to define the Agent.
  • A.3 Transformer Constitution: Defines the TransformerRole that the Agent plays.
• Enables and Constrains:
  • A.10 Evidence Graph Referring: Provides the causal structure (who did what) that evidence must be anchored to.
  • B.2 Meta-Holon Transition (MHT): A Reflexive Split is often the first step in identifying an emergent supervisory layer that may later be promoted to a new meta-holon.
  • B.2.5 Supervisor-Subsystem Feedback Loop: This pattern provides the detailed architecture for the Regulator-Regulated interaction that the Reflexive Split reveals.

#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 and the principle of the external agent.

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 Characterization (Agency-CHR), 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 U.Agent as a new base type 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 as an agent in one context and 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 an Agent 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: Agent as a Contextual Role Assignment

An "Agent" in FPF is not a fundamental type. It is a convenience term (a Register 1 / Register 2 label) for a specific kind of Contextual Role Assignment (U.RoleAssignment):

Agent ≍ U.RoleAssignment(holder: U.System, role: U.AgentialRole, context: U.BoundedContext)

This means an Agent is simply a U.System that is currently playing an AgentialRole within a specific U.BoundedContext.

• No U.Agent Type: To be clear, there is no U.Agent base type in the FPF Kernel. This avoids type inflation and preserves the dynamic nature of roles.
• Epistemes Cannot Be Agents: As the holder must be a U.System, this definition constitutionally forbids U.Epistemes from being agents, preventing the "episteme-as-actor" category error.
• Canonical Syntax: The technical notation for an agent is System#AgentialRole:Context.

#The AgentialRole and its Specializations

• U.AgentialRole: This is the abstract U.Role that grants a U.System the capacity for goal-directed action within a context. It is the "license to act."
• Specialized Roles: More specific behavioral roles like TransformerRole and ObserverRole are considered specializations or sub-roles of AgentialRole. They describe what kind of agential action is being performed at a given moment.
  • A system playing TransformerRole is an Agent that is currently modifying another holon.
  • A system playing ObserverRole is an Agent that is currently gathering information. This creates a clean hierarchy: a Transformer is always an Agent, but an Agent is not always a Transformer (it could be observing, planning, or idle).

#Measuring Agency: The Agency-CHR and the Spectrum

Agency is not a binary switch; it is a multi-dimensional spectrum of capabilities. FPF models this using a dedicated pattern, Agency-CHR (C.9), which is a Characterization that attaches a set of measurable properties to a U.RoleAssignment.

The Agency-CHR profile is grounded in contemporary research (e.g., Active Inference, Basal Cognition) and includes the following key characteristics. Each is measured for a specific agent 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 agent'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 agent 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 kernel type. 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-CHR 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 CHR profile into an intuitive autonomy grade.

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

#Archetypal Grounding

The universal pattern of agency, defined as a Contextual Role Assignment and measured by the Agency-CHR, 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 agent.

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 the actions of an agent (like the DevOps team), but it is never an agent 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-CHR provides a direct, practical implementation of these ideas.
• Ontologically Sound: By defining an Agent 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-CHR 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: The actions of an Agent are modeled using the external transformer principle.
• Coordinates with:
  • B.2 Meta-Holon Transition (MHT): A significant jump in the Agency-CHR of a collective can trigger an MHT.
  • B.3 Trust & Assurance Calculus: The Agency-CHR profile provides crucial inputs for assessing the reliability and safety of an autonomous system.
  • D.2 Multi-Scale Ethics Framework: The Agency Grade is used to determine the moral-responsibility posture and accountability assigned to a system.
• Instantiates:
  • The Agency-CHR (C.9), which provides the formal definitions for the characteristics (BMC, PH, etc.).

#A.13:End

#Advanced Mereology: Components, Portions, Aspects & Phases

#Context — why an advanced mereology?

FPF’s holonic modelling relies on part–whole relations to build structural and conceptual holarchies (systems and epistemes). But U.Holon is not synonymous with “mereological whole”: some holons (notably Roles and Methods) are bounded identity‑bearing objects whose primary composition is handled by other algebras (A.2 role algebra; A.15 method/description graphs), not by partOf. 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 Roles and Methods (as intensional masks/ways‑of‑doing) outside mereology (A.15), while allowing their describing epistemes (e.g., U.MethodDescription, U.WorkPlan) to use ordinary episteme parthood and versioning like any other U.Episteme. It also clarifies how MemberOf fits (preview: collections are grounded constructively in C.13 Compose‑CAL via Γ_m.set; collective agency/composition is handled outside A.14 via B.1.7 Γ_collective and A.15, not via partOf).

Publication note (Working‑Model first). Read A.14 together with E.14 Human‑Centric Working‑Model and B.3.5 CT2R‑LOG: publish relations on the Working‑Model surface; when assurance is sought, ground downward. For structural claims that require extensional identity, use the Constructive shoulder via Compose‑CAL Γ_m (sum | set | slice); order/time stay outside mereology (Γ_time / Γ_method).

#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 Roles/Methods in mereology. U.Role and U.Method are never parts (A.15). A U.MethodDescription is an Episteme and may be versioned/structured; that does not make the described U.Method a part.
4. MemberOf stays, but constructive aggregation and agency live elsewhere. MemberOf remains available to state collections and collectives; a collection‑as‑whole may be constructed via Γ_m.set (Compose‑CAL, C.13), while collective agency/composition is handled in B.1.7 Γ_collective and A.15 (not in A.14).

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)

• Structural claims published on the Working-Model surface SHALL be justified, when assurance is required, by a Constructive grounding narrative using Γ_m.sum | Γ_m.set | Γ_m.slice and linked with tv:groundedBy (see B.3.5; C.13).
• PhaseOf is temporal parthood; it SHALL NOT be grounded via Γ_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). When modelling a collection‑as‑whole for assurance purposes, the constructive basis is Γ_m.set; no ComponentOf inferences follow from MemberOf.

#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 (System / Episteme)

#Conformance Checklist & type guards (normative)

#Global firewall and scope

#PortionOf guards

#PhaseOf guards

#Anchoring & validation (normative)

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

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

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

#Validation patterns (author’s 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 mereology; go to A.15 (Role–Method–Work). If it is about the carrier episteme (pages/sections/versions of an SOP/algorithm/spec), you may still be in A.14.

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) for constructive grounding. If you need collective action, apply A.15.

Quick spot‑tests (repair kit).

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

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

#Pedagogy aids (non‑normative)

Two‑minute checklist for reviewers

1. Do I see “process/workflow/policy/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.

#Patch map (where to touch in the working file)

1. Kernel - Holonic Mereology (§ A.1 → A.14) Add sub‑sections “PortionOf” and “PhaseOf” with axioms (POR‑1..5, PHA‑1..5). Move MemberOf note to a minimal semantics paragraph (no composition here).

2. A.15 (Role–Method–Work) Cross‑link firewall (CC‑A14‑0/0b) and reinforce that versioning uses PhaseOf only on MethodDescription/Work.

3. B.1.2 Γ_sys, B.1.3 Γ_epist, B.1.4 Γ_ctx and Γ_time, B.1.5 Γ_method, and B.1.6 Γ_work Insert a one‑line “A.14 compliance” note: which A.14 sub‑relations each flavour relies on, as in § 10.

4. Examples & Annexes Refactor any “percentage as part” examples into PortionOf with declared μ; Split any overlapping histories into PhaseOf sequences.

Each edited heading should carry the badge “► decided‑by: A.14 Advanced Mereology”.

#Rationale (state‑of‑the‑art alignment, post‑2015)

• 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 workflows 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.

#A.14:End

#Role–Method–Work Alignment (Contextual Enactment)

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, capability, and actual 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 actual run, and the team keeps arguing over a source-side "process" cue without separating recipe, plan, capability, and executed work.

First output. One explicit separation of U.Role, U.Method, U.MethodDescription, U.WorkPlan, and U.Work, plus the shortest traceable chain that already exists from U.RoleAssignment through the governing U.Method and its method-description source to the intended U.WorkPlan or actual U.Work occurrence, or an explicit source gap that blocks admission of the claim.

Working enactment-alignment spine. Role, method, plan, and work confusion -> separate role, holder, bounded context, method description, intended U.WorkPlan, and actual U.Work -> 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 project move -> 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 chain begins to carry or justify a work claim or reliance claim.

Working application moves.

1. Name the role, holder, and context distinction under repair.
2. Name the method or method description that is meant to govern the work.
3. Name the intended U.WorkPlan or actual U.Work occurrence being claimed.
4. Choose the next move: 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 an encountered source candidate or display is being used by appearance for a work claim, reliance claim, or source-restoration claim, apply A.15.4 Work-Relevant Source Restoration to that source-restoration claim; keep A.15 only for the U.Role, U.Method, U.MethodDescription, U.WorkPlan, and U.Work separation.

Action-pattern protection. This pattern is not about classifying encountered publications, displays, or cues. It keeps role, method, plan, capability, and actual work distinct so the acting engineer-manager can choose the next admissible project move. Work-relevant source restoration is handled by the related A.15.4 cluster member.

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

Recovered-source ready 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 move under repair, proceed inside that recovered scope and window. If not, narrow scope, run a bounded reversible probe, source-find, or create only the smallest source-restoration request, decision-request record, prospective work-plan entry, source-gap note, or missing-source admission block needed for the next move.

Ordinary use. If the team only needs to separate role, method, plan, capability, and actual work for orientation or planning, one separation sentence or small working card is enough.

Reliance-bearing use. Use the fuller alignment frame when an encountered source candidate or display is about to guide planned work, actual work, role attribution, status attribution, release reliance, disputed responsibility, or cross-context use. Use A.15.4 when the issue under repair is whether that source candidate exposes the project-side FPF kind and reference named by value needed for that work claim or reliance claim.

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

Admissible-use examples.

Alignment frame in plain terms. One alignment frame linking U.Role, U.Method, U.MethodDescription, U.WorkPlan, and U.Work through U.RoleAssignment; not a single work occurrence, not a checklist, not a language-style repair pattern, and not a mere cue note.

First admissible project move in plain terms. Keep design-time role, method, and work plan distinct from run-time work while making the chain between them inspectable enough for enactment, audit, and source restoration.

What goes wrong if missed. Teams collapse role, recipe, plan, capability, and actual run into one fuzzy source-side "process" label, then mistake documentation for execution, capability for evidence, schedule for occurrence, or a narrower briefing for the source 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 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 source restoration for an encountered source candidate or display (A.15.4).

Related project records and governing patterns. A.15.1 governs dated execution records, A.15.2 schedule or baseline planning records, A.15.3 slot-filling plan items, A.15.4 work-relevant source restoration, 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 U.MethodDescription, U.WorkPlan, and U.Work structures here. 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 encountered source 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 only need one executed occurrence rather than the alignment frame, recover the A.15.1 dated work-occurrence record; if an encountered source candidate or display 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, source-restoration note, wording repair, assurance claim, or source-side "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), what it is supposed to do (its role and specified capability), and what it actually does (its work). Confusing these distinctions is a primary source of design flaws, budget overruns, and failed projects. Teams argue over a source-side "process" cue without clarifying whether the FPF object under repair is a U.Method, a U.MethodDescription, a U.Capability, a U.WorkPlan, or a specific U.Work occurrence that happened last Tuesday.

This pattern provides the canonical alignment for modeling contextual enactment in FPF. It applies the Strict Distinction Principle (A.7) to the passage from intended work to planned and actual U.Work, 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 U.Role values and U.RoleAssignment as the typed work-facing assignment relation with holder, role, bounded-context, window, and justification slots governed through A.6.5-style slot discipline.
• A.15.2 and A.15.1: Separate U.WorkPlan intent windows from dated U.Work occurrences.
• A.3.1 and A.3.2: Separate U.Method from U.MethodDescription, so recipes, algorithms, procedures, and source-side "process" cues 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, source, publication, 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 describing the passage from role and method capability to planned and actual, resource-consuming U.Work.

To keep plan-run separation explicit, this pattern references A.15.2 U.WorkPlan for schedules and calendars and A.15.1 U.Work for dated execution. Ambiguous source terms like "process", "workflow", "activity", and "schedule" are handled by E.10 and E.10.ARCH: recover the project concern first, then assign the source cue to U.Method, U.MethodDescription, U.WorkPlan, U.Work, 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 kind being claimed: U.Method, U.MethodDescription, U.Work, U.WorkPlan, or a neighboring governed value such as U.Transformation, U.Dynamics, evidence, gate, source, 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-Context: An instance of work is logged without a clear link back to the role, capability, and specification that governed it, making the work unauditable and its results impossible to reproduce.
5. Ambiguous source-side "process" or "activity" cue: 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), U.Work (run), or another direct governing pattern.

#Forces

#Solution

Method and work governing-pattern cue. When a source-side "process", "algorithm", "solver", "workflow", "procedure", or similar label points to changing, producing, selecting, deriving, controlling, or maintaining an EntityOfConcern, use E.10.ARCH:3.1 to recover the project concern 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, gate, source, 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 MethodRelationStructure@BoundedContext 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 the design-time and run-time for contextual enactment. The bridge between these worlds is the 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) Design-Time Entities (The World of Potential):

• U.Role: A contextual "mask" or "job title" (e.g., TesterRole). It specifies expected contribution or responsibility in a bounded context; it is not the holder, method, capability, work plan, or work occurrence.
• U.Method: The abstract way-of-doing inside a context (paradigm-agnostic; may be imperative, functional, logical, or hybrid).
• 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: An attribute of a U.System that represents its ability to enact the declared U.Method under stated conditions. A MethodDescription may describe that method; the capability is not the description and not the work occurrence.
• U.WorkPlan: An U.Episteme declaring intended U.Work occurrences (windows, dependencies, intended performers as role kinds, budgets) - see A.15.2.

B) The Bridge Entity:

• U.RoleAssignment: The typed work-facing assignment relation that links a holder system or acting holon, a U.Role, a U.BoundedContext, any current window, and justification or source references when they matter.

C) Run-Time Entity (The World of Actuality):

• U.Work: An occurrence or event. It is the concrete, dated, resource-consuming enactment or execution of a U.Method by a Holder acting under a U.RoleAssignment; capability checks are evaluated at run time against the holder, and methodDescriptionRef names the source episteme used to identify or constrain the method when that source is being used for the work claim. This is the only entity that has a start and end time and consumes resources.

Kinds of Work and the primary target

Well-formedness constraint A15-WF-1 (work target and kind). A U.Work occurrence has primaryTarget: U.Holon with cardinality 1..1 (total) and kind with cardinality 1..1 (total).

Local kind values used here:

• Operational - transforms a U.System or its environment.
• Communicative (SpeechAct) - transforms a deontic or organizational frame (e.g., commitments, authority effects, approvals).
• Epistemic - transforms a U.Episteme (e.g., curating a dataset). The primaryTarget disambiguates enactment: what is being acted upon. Example: an approval is kind=Communicative, primaryTarget = Commitment(change=4711). A deployment is kind=Operational, primaryTarget = ServiceInstance(prod-us-eu-1).

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. They have this skill even when they are not cooking.
• The restaurant's rulebook (U.BoundedContext) states that a holder assigned to ChefRole needs the capability to follow the recipes in the cookbook before the relevant cooking work is admitted.
• The actual act of making a souffle on Tuesday evening - using eggs and butter, taking 25 minutes, and consuming gas - is the U.Work.

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 entities are connected by precise, normative relations that form a traceable alignment chain. The following diagram illustrates the relation chain from bounded context and method description to dated work occurrence.

graph TD
    subgraph Design-Time Scope (Tᴰ)
        A[U.BoundedContext] -- defines --> B(U.Role)
        M[U.Method] -- isDescribedBy --> D[U.MethodDescription]
        Cap[U.Capability] -- is capability for --> M
        H(U.System as Holder) --> RB(U.RoleAssignment)
        B -- is the role in --> RB
        A -- is the context for --> RB
        A -- bindsCapability(Role,Capability) --> Cap
    end

    subgraph Run-Time Scope (Tᴿ)
        W[U.Work]
    end

    W -- performedBy --> RB
    W  -- enactsMethod --> M

    style A fill:#e6f3ff,stroke:#36c,stroke-width:2px
    style B fill:#fff2cc,stroke:#d6b656,stroke-width:2px
    style Cap fill:#d5e8d4,stroke:#82b366,stroke-width:2px
    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 RB fill:#dae8fc,stroke:#6c8ebf,stroke-width:3px,stroke-dasharray: 5 5
    style W fill:#ffe6cc,stroke:#d79b00,stroke-width:2px,font-weight:bold

• bindsCapability(Role, Capability): A U.BoundedContext asserts that a given Role requires a specific Capability. This is a design-time rule.
• isDescribedBy(Method, MethodDescription): A U.Method is formally described by one or more MethodDescriptions. This links the abstract way-of-doing to the method-description episteme and to the publication used when that source is being used for the method claim.
• enactsMethod(Work, Method): A specific U.Work is a run-time enactment of a U.Method under a U.RoleAssignment. Capability checks are evaluated against the holder at run time; the MethodDescription remains the source episteme or method-description reference used to identify, constrain, or justify the method when that source is being used for the work claim.
• performedBy(Work, RoleAssignment): A U.Work is performed by the holder named through a specific U.RoleAssignment. This links the work occurrence to the holder-in-role-in-context.

At run time, capability thresholds declared by the context or specification are checked against the holder; U.Work outcomes provide evidence for capability conformance.

This chain provides complete traceability: a specific instance of U.Work can be traced back to the U.Method it enacts, the MethodDescription or source publication used to identify or constrain that method, and the U.RoleAssignment relation whose holder, role, bounded-context, and current-window slots make the work-facing assignment explicit.

#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 move, 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 move 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 move or reliance move: 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, performed U.Work, execution evidence/provenance relation, or 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/provenance relation by value.

#Boundary to A.15.4 Work-Relevant Source Restoration

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 chain is being used by appearance for a work claim, reliance claim, role-assignment currentness claim, status currentness claim, approval, permission, gate passage, evidence, engineering justification, release reliance, or performed U.Work.

A.15 itself keeps the kernel separation: U.Role, holder, context, U.Method, U.MethodDescription, U.WorkPlan, actual U.Work, and the U.RoleAssignment chain between them. The source-restoration question recovers the project-side FPF kind and reference named by value before the encountered source candidate or display can carry the work claim, reliance claim, or effect claim being made; that question belongs to A.15.4 or to the source-restoration pattern governing that reliance named there.

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.

#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: This side-by-side comparison reveals the power of the framework. A seemingly different activity like welding a car chassis and reviewing a scientific paper are shown to have the same underlying enactment structure. Both involve a Holder (a system) acting in a Role within a Context, using a Capability to enact a U.Method, citing a MethodDescription when a recipe or source is used to identify or constrain the method, and producing a specific, auditable instance of Work. This universality is what allows FPF to compare and align disparate domains without collapsing their local structure.

#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 paths 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 path.

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, performed U.Work, 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 run is recorded.

This publication may guide method inspection and work-planning preparation under A.15. A conforming use keeps selected method, U.WorkPlan, actual U.Work, work-result record, and result measurement distinct. If the publication is used for evidence, provenance, engineering justification, gate or constraint decision, material carrier, 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 a source-restoration request, decision-request record for the next decision, prospective work-plan entry, or explicit source-gap 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 the source episteme or source publication 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, record that project choice or plan as the selected A.15 selected-method, work-plan, or work-occurrence record named by value. If the scenario is used for evidence, gate, or engineering-justification reliance, first recover the project evidence path, gate or constraint decision, or engineering-justification record named by value under A.10, A.20, A.21, or B.3; otherwise record only a source-restoration request, decision-request record, prospective work-plan entry, or source-gap note.

#Bias-Annotation

Lenses tested: Gov, Arch, Onto and Epist, Prag, Did. Scope: Universal for contextual enactment 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, and U.Work distinct, and let only U.Work carry actuals and resource use.
• Architectural bias (Arch): modelers may pull roles or capabilities into structural part hierarchies because those diagrams are already present. Mitigation: preserve role and capability as context-bound assignment and ability values, not parts.
• Epistemic bias (Onto and Epist): a documented recipe or schedule can be mistaken for proof of execution. Mitigation: require the traceability chain from U.RoleAssignment and U.MethodDescription to dated U.Work.
• Pragmatic bias (Prag): teams may keep using one overloaded source-side "process" word because it feels faster. Mitigation: resolve "workflow", "schedule", and "what happened" source cues through U.Method, U.MethodDescription, U.WorkPlan, and U.Work.
• 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 or U.Capability inside structural partOf decomposition; keep role as contextual assignment value and capability as ability value under stated conditions.
• Recipe-as-evidence. A U.MethodDescription or SOP may identify or constrain a method; dated U.Work records carry the occurrence claim.
• Plan-as-actual. Do not let schedules, calendars, or intended assignments stand in for actual execution; use U.WorkPlan for intent and U.Work for actuals.
• Capability-as-work. Do not treat possession of a capability 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 step they permit; model them as communicative U.Work when they institute a role, gate, or commitment effect.
• Process soup. Do not leave "process", "workflow", or "activity" uninterpreted in FPF-governed passages; resolve the source cue to U.Method, U.MethodDescription, U.WorkPlan, or U.Work.
• Briefing-as-execution-cue. A lighter review note, rollout summary, or redacted operations note may orient work; use A.15.4 or the source-restoration pattern governing 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 moves 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.
• Source candidate or display as work source. A dashboard tile, credential display, copied approval, generated explanation, provenance label, command-like cue, or composed source chain is only a source candidate until A.15.4 recovers the project-side kind and reference named by value needed 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 performed occurrences such as 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, and dated U.Work. The U.Work entity can be seen as an occurrence recognized by such a source tradition, but FPF adds the crucial context of the Role, Capability, enacted U.Method, and MethodDescription source that make the occurrence inspectable.
• Pragmatism and Practice: The framework is deeply pragmatic. The distinctions it makes (e.g., between a MethodDescription and U.Work) are precisely the ones that matter in the real world of project management, compliance, and debugging. When a failure occurs, a manager needs to know: was the recipe wrong (MethodDescription), did the chef lack the skill (Capability), or did they just make a mistake this one time (U.Work)? 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 Alignment: 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, and U.Work, and rejects the shortcut where one undifferentiated "process" label carries all three meanings.

Claim 2. Best-known current accountability practice keeps actor-in-context 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 actual run 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 actor-in-context attribution through U.RoleAssignment, adapts it to bounded-context semantics, and rejects anonymous work logs and role-as-part modeling.

Claim 3. Best-known current approval and execution practice treats communicative gate acts and operational acts as distinct kinds of work.

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, that means an approval is not the same work as a deployment or a weld. This pattern adopts that split, adapts it through communicative versus operational U.Work kinds, and rejects the collapse of approval into the thing being approved.

Local claim. The FPF-governed SoTA claim for this pattern is practical and narrow: contextual 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 run 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

• 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, and A.15.3 for slot-filling plan items.
• Coordinates with: A.15.4 for work-relevant source restoration; E.10 and E.10.ARCH for source cue 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; 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 source-restoration claims 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 moves:

1. Name the role, method, and work result before naming any distributed state.
2. State which work traces, records, events, observations, reports, metrics, U.Work occurrences, or RoleEnactmentFact records 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 path or B.3 assurance claim path 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, performed U.Work and work-result record for execution, and an A.15.4 source-restoration reference when the issue is work-relevant source restoration. 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 relation, this family carries the split among selected method, U.WorkPlan, SlotFillingsPlanItem, performed U.Work, and 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. 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 record.

#P2W Performed-Work Relation

When E.18.1 reaches performed work, this family keeps the current kind as U.Work. WorkEnactment wording is explanatory only: it points to dated performed work, not to a second work kind.

A performed-work record may cite a U.WorkPlan and planned baseline, while recording launch values, actuals, substitutions, variance, telemetry, outputs, outcome, and result-related records in the performed-work occurrence. Comparator, transport, PrincipleFrame, U.Signature(profile=FormalSubstrate), evidence, assurance, and gate relations are named separately when those claims are being made.

#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 performed 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, bounded context, method, method description, work plan, performed work occurrence, or capability check cannot be named at the granularity required by the next work move. A weaker but admissible result is a separation note, source-gap note, source-restoration request, decision-request record for the next decision, or prospective work-plan entry.

Repair the local alignment frame when a subsequent source shows that the role assignment, method description, work-plan baseline, performed-work occurrence, capability threshold, status-currentness record, or source-currentness window was wrong for the claimed move. 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 path changed, and do not treat a source-restoration request as carrying a non-A.15 claim.

Refresh the A.15 use before relying on it across a new context, new role assignment, new method family, new work plan, new execution window, new result measurement, or new evidence, assurance, gate, source-restoration, 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 when the current claim is a performed occurrence: a dated, resource-consuming occurrence enacted by a holder under U.RoleAssignment, inside a U.BoundedContext, with method, time window, parameter bindings, resources, affected referent, result, and evidence relations kept inspectable.

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 occurrence; surrounding records may identify, constrain, evidence, schedule, publish, or judge it, but they do not become the occurrence by being published.

First output. One work-occurrence record naming performedBy -> U.RoleAssignment, enactsMethod -> U.Method, methodDescriptionRef when the source episteme is current, executedWithin, time window, concrete parameter bindings, affected referent, resource ledger, pre-state and post-state references or a declared delta predicate, outcome, and the governing U.BoundedContext.

First-use checks.

1. Name the candidate occurrence and the work-facing claim that depends on it.
2. Recover the U.RoleAssignment, enacted U.Method, method-description source, time window, system or subsystem accountable for the occurrence, affected referent, parameters, resources, outcome, and evidence relation when current.
3. Decide whether the encountered record, trace, or source candidate or display is performed 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 a work-relevant source-restoration case (A.15.4).
4. For composite, repeated, interrupted, or overlapping occurrences, declare the work-part relation and aggregation policy before using totals or identity claims.
5. If the required occurrence references cannot be recovered, lower the claim to a source-gap note, work-evidence note, plan note, publication-use note, declarative-representation note, or source-restoration request; do not backdate work.

Ordinary use. For a simple occurrence, one compact work card with performer, method, time window, affected referent, resources, and outcome is enough.

Reliance-bearing use. Use the full record when cost, quality, audit, evidence, conformance, gate, release, result measurement, cross-context reuse, or aggregation claims depend on the work occurrence.

Stop condition. Stop once the occurrence is either recoverable as 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 record that keeps performer, role assignment, enacted method, method-description source, time window, affected referent, resources, outcome, evidence relation, and repair boundary inspectable.

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 a SlotFillingsPlanItem (A.15.3), only a visible source cue that needs source restoration before reliance (A.15.4), 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), and how in principle the work is done (via U.Method or U.MethodDescription), we still need a precise concept for what happened as performed work in real time and space.

That concept is U.Work: the dated run-time occurrence of enacting a U.Method by a specific performer under a U.RoleAssignment, with concrete parameter bindings, resource consumption, and outcomes, naming the domain referent changed by the occurrence (asset, product, or dataset) - not merely the manipulation of records about that referent. Managers care about Work because cost, time, defects, and result evidence are booked on performed occurrences. Architects care because Work ties plans and method descriptions to accountable performed work.

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

1. Plan and run 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 booked to methods or roles, not to performed work occurrences; costing and sustainability measures drift.
5. Mereology muddle. Teams hand-wave over sub-runs, retries, overlaps, or long-running episodes; roll-ups double-count or miss work.

#Forces (what the definition must balance)

#Solution — define U.Work as the accountable, dated occurrence

#Definition

U.Work is a 4D occurrence holon: a dated run-time enactment of a U.Method by a performer designated through a U.RoleAssignment, executed within a concrete U.System or U.SubSystem, inside a U.BoundedContext, that binds concrete parameters, consumes and produces resources, and leaves an auditable trace. When a method-description source is current, methodDescriptionRef names the U.MethodDescription used to identify, constrain, or justify the enacted method. When the current claim needs a formal state-change witness, represent the occurrence through a morphism Δ on a declared state-plane (StatePlaneRef), mapping pre-state plus inputs to post-state plus outputs for one or more affected referents. The work itself remains the dated occurrence; the morphism is the selected mathematical-lens expression for its delta claim.

Memory aid: Work = “how it went this time” (dated, resourced, accountable).

#Core reference descriptors (conceptual descriptors; not a data schema)

When you describe a Work instance in a review, answer these prompts:

1. Window — start and end timestamps and, where relevant, location or asset.
2. Method-description source — methodDescriptionRef -> U.MethodDescription when the description source is current; edition pinned when reliance depends on edition.
3. Performer — performedBy → U.RoleAssignment (whose holder slot, role value, and bounded-context slot admit the performer).
4. Parameters — concrete values bound for this run (from the MethodDescription parameter declarations).
5. Inputs and outputs — materials, information, or product states used or produced by the Work; service delivery is judged through the Outcome row.
6. Resources — energy, materials, machine time, money (the only place we book them).
7. Outcome — success and failure classes, quality measures, acceptance verdicts (map-then-compare per ComparatorSet under CG-Spec; pin editions).
8. Links — predecessor, successor, and overlap relations to other Work, plus step or run nesting if part of a bigger operation.
9. Context — the bounded context under which this run is judged, normally inherited from the method-description source and U.RoleAssignment; see A.15 for cross-checks.
10. Effect (Δ) — affected → {referent(s)} + pre-state reference and post-state reference (or a declared Δ-predicate evaluated on evidence) on the declared state-plane (StatePlaneRef).
11. System — executedWithin -> U.System or executedWithin -> U.SubSystem (the operational system or subsystem accountable for the occurrence; required for admitting the performed-work claim).
12. Evidence and telemetry references (when current) — if the run feeds G.11 refresh or QD and OEE archives, cite the telemetry, evidence, archive, and policy references declared by the governing comparison, archive, evidence, or refresh pattern; do not elevate telemetry into dominance without the governing comparison or archive policy.

#Clear distinctions (the four‑slot grammar in action)

#Publication-use boundary for U.Work

A U.Work publication projects an already declared work occurrence; it does not create the occurrence, add run-time facts, or make a plan, source reconstruction, dashboard, or publication face count as performed work.

#Crossing visibility for work publications

When a work publication crosses design-time state, run-time state, context, reference plane, unit, or edition, publish the crossing relation used by the publication. Penalties and reliability changes belong to the relevant comparison, bridge, publication, or evidence relation; they do not change the identity of the U.Work occurrence.

Launch values bind only at the occurrence. Plan-time proposals remain proposals; do not back-fill plan publications with run-time bindings. Pre-state and post-state references bind to the occurrence: pre at start, post at completion or at declared checkpoints.

#Work mereology (how runs form holarchies)

We adopt a 4D extensional stance for occurrences: a Work is identified primarily by its spatiotemporal extent and its occurrence references (method-description source when current, performer, parameterization). This avoids double-counting and keeps aggregation sound. FPF adapts insights from BORO and constructive ontologies to Work while staying practical.

#Parts and wholes of Work (design‑neutral, run‑time facts)

• Temporal‑part (TemporalPartOf_work). A proper time‑slice of a Work (e.g., the first 10 minutes of a 2‑hour run). Useful for monitoring and SLAs.
• Episode‑part (EpisodeOf_work). A resumption fragment after an interruption (same run identity if policy deems it one episode; see 5.5).
• Operational-part (OperationalPartOf_work). A sub-run that enacts a factor of the Method or method-description source, for example, an incision run within an appendectomy run, possibly overlapping with others in time.
• Parallel‑part (ConcurrentPartOf_work). Two sub‑runs that overlap in their windows, coordinated by the same higher‑level run.

Didactic rule: Method composition ≠ proof of Work decomposition. Sub‑runs often map to method factors, but retries, batching, pipelining, and failures make the mapping non‑isomorphic.

#Key relations among Work

• precedes or happensBefore — strict partial order on Work windows.
• overlaps — intervals intersect but neither contains the other.
• contains or within — one Work's window contains another's.
• Causal-use relation reference — if one work occurrence is claimed to explain, trigger, or cause another, keep the work-occurrence link separate from the causal-use claim governed by C.28 or another causal-use pattern named by value.
• retryOf — a new Work instance re‑attempting the same MethodDescription with revised parameters.
• resumptionOf — a Work episode that continues an interrupted run (policy decides identity; see 5.5).

These relations are run‑time facts, not design assumptions.

#Operators for roll‑ups (Γ\time and Γ\work)

• Temporal coverage — Γ_time(S) For a set S of Work parts, returns a coverage interval set (union of intervals) or, when required, the convex hull [min t₀, max t₁]. Use union for utilization; use hull for lead time. Properties: idempotent, commutative, monotone under set inclusion.

• Resource aggregation — Γ_work(S) For a set S of Work parts, returns the aggregated resource ledger (materials, energy, time, money) with de-duplication rules for shared and overlapped parts (context-declared). Properties: additive on disjoint parts; requires overlap policy otherwise (e.g., attribute costs to the parent once, not to each child).

Manager’s tip: Pick the coverage operator that matches your KPI: union for machine utilization; hull for calendar elapsed; never mix silently.

#Identity of a Work (extensional criterion, pragmatically framed)

Two Work records refer to the same Work iff, in the relevant context:

• their time–space extent is the same (within declared tolerance),
• they link to the same MethodDescription,
• they have the same performer (U.RoleAssignment), and
• they bind the same parameters (or declared‑equivalent values).

If any of these differ (or the context declares equivalence absent), they are distinct Work instances (e.g., a retry).

#Interruptions, retries, resumptions (episode policy)

• Retry: new Work with its own window and parameters; link via retryOf.
• Resumption: same Work identity split into episodes if the context’s episode policy declares so (e.g., “power loss under 5 minutes keeps identity”).
• Rework: new Work initiated after a failure in earlier Work; link the occurrences and put any causal attribution in the governing causal-use pattern.

Why it matters: plans, costs, and quality stats depend on whether you treat a disruption as one episode or a new run. Declare the policy in the bounded context.

#Compositionality of effects (Δ)

For any work occurrence with parts, the effect of the whole is the rules-declared composition of the effects of its parts plus any declared overheads and residuals. Composition aligns with the overlap rules used by Gamma_work, such as no double-count of shared fixed costs and consistent attribution of variable deltas.

#Archetypal grounding (parallel domains)

#Surgical case (overlap and episodes)

• Top run: Appendectomy_Case_2025-08-10T0905_1142.
• Method-description source: Appendectomy_v5.
• Performer: U.RoleAssignment with holder slot OR_Team_A, role value SurgicalTeamRole, bounded-context slot Hospital_2025, and current-window slot covering the surgery interval.
• Operational parts: Incision (09:15–09:22), Exploration (overlaps with monitoring), Closure (11:10–11:35).
• Episode: brief power dip 10:02–10:07 → resumptionOf same run (per hospital policy).
• Γ_time: union for OR utilization; hull for patient lead time.
• Γ_work: totals consumables and staff time once (no double‑count for overlapping sub‑runs).

#ETL pipeline (parallelism and retries)

• Top run: ETL_Nightly_2025‑08‑11T01:00–01:47.
• Method-description source: ETL_v12.bpmn.
• Performer: U.RoleAssignment with holder slot ETL_Runtime, role value TransformerRole, bounded-context slot DataOps_2025, and current-window slot covering the ETL run.
• Parallel parts: Extract_A ‖ Extract_B; Transform starts when either completes (overlap).
• Retry: WarehouseWrite failed at 01:36; retried with batch size ↓ — new Work linked via retryOf.
• Γ_time: hull for SLA, union for cluster utilization.
• Γ_work: sum compute minutes; attribute storage input and output once at the parent.

#Thermodynamic cycle (work through a state-plane trace)

• Run: Carnot_Cycle_Run_2025-08-09T1300_1306.
• Method-description source: Carnot_Cycle_Spec with Dynamics model.
• Performer: U.RoleAssignment with holder slot LabRig_7, role value TransformerRole, bounded-context slot ThermoLab, and current-window slot covering the lab run.
• Work identity: the occurrence is identified by the run interval plus occurrence references; the thermodynamic state-plane trace is a dynamics or geometry relation used to describe the change, not a work-control relation or ordered instruction sequence.
• Γ_time: straightforward interval; Γ_work: integrates energy exchange; no “steps” required.

#Scope Declaration and Rationale

• Applicability: Use the same occurrence test for pragmatic costing, architectural accountability, teaching examples, and source or evidence questions; when the current claim is only about a description, publication, source, or evidence relation, apply the governing pattern for that claim.
• Scope declaration: Universal; temporal semantics and episode policy are context‑local via U.BoundedContext.
• Rationale: Gives FPF a clean, actionable notion of occurrence compatible with U.RoleAssignment, direct Work.performedBy = RoleAssignment wording, and derived RoleEnactmentFact when a named fact is needed, so that costing, quality, and audit rest on runs, not on plans or recipes.

#Conformance Checklist (admission checks)

CC-A15.1-1 (Strict distinction). U.Work is a dated run-time occurrence. It is not a U.Method (semantic way), not a U.MethodDescription (description), not a U.Role or U.RoleAssignment (assignment), and not a U.WorkPlan (plan or schedule).

CC-A15.1-2 (Required links). A conforming U.Work claim names: (a) enactsMethod -> U.Method (the method enacted), (b) methodDescriptionRef -> U.MethodDescription when the source episteme or editioned method description is current, (c) performedBy -> U.RoleAssignment (the assigned performer in context), and (d) executedWithin -> U.System or executedWithin -> U.SubSystem (the operational system or subsystem accountable for the occurrence).

CC-A15.1-3 (Time window). A conforming U.Work claim carries a closed interval [t_start, t_end], or an explicitly marked open end for in-flight work, and, where relevant, location or asset.

CC-A15.1-4 (Context reference and judgement). A U.Work claim is judged inside a declared U.BoundedContext (the judgement context).

• By default, the judgement context is the context of the referenced method-description source.
• If performedBy references a U.RoleAssignment in a different context, cross-context acceptance needs an explicit bridge relation or policy. Otherwise the work claim is not admitted in that context.

CC-A15.1-4b (State-plane reference). The work claim names the StatePlaneRef used for its delta judgement.

CC-A15.1-5 (RoleAssignment interval coverage). The performedBy U.RoleAssignment timespan covers the work interval. If it does not, lower the claim to a non-admitted role-assignment relation for that context or re-judge it in a context that admits retroactive assignments.

CC-A15.1-6 (Parameter binding). Parameters declared by the U.MethodDescription have concrete values bound at work creation or start and recorded with the work occurrence. Defaults in the method description do not by themselves admit the performed-work claim.

CC-A15.1-7 (Capability check). Capability thresholds stated by the U.Method or U.MethodDescription are checked against the holder in performedBy for the performed-work interval or declared checkpoints. Violations are recorded on the work outcome.

CC-A15.1-8 (Acceptance criteria). Success and failure classes and quality grades are determined by the acceptance criteria declared or referenced by the U.MethodDescription or comparator specification in the judgement context. The verdict is recorded on the work occurrence.

CC-A15.1-9 (Resource honesty). Performed consumptions and costs (energy, materials, machine-time, money, tool wear) are booked to U.Work, not to U.Method, U.MethodDescription, U.Role, or U.Capability. Estimates belong in method descriptions or plans; performed values belong in work occurrences.

CC-A15.1-10 (Mereology declared). When a work occurrence has parts, the selected part relation is declared: temporal-part, episode-part, operational-part, or concurrent-part. Ambiguous mixtures lower aggregation and identity claims.

CC-A15.1-11 (Temporal coverage selection). For a roll-up, the judgement context declares which temporal coverage operator applies: union for utilization or convex hull for lead time. Silent mixing lowers the KPI or comparison claim.

CC-A15.1-12 (Resource aggregation). Aggregation of resource ledgers across work parts names an overlap policy, such as attributing shared machine-time to the parent only, before totals are used.

CC-A15.1-13 (Identity and retries). A retry is a new U.Work occurrence linked via retryOf. Interruptions treated as the same run are represented as episodes (resumptionOf) under a context-declared episode policy.

CC-A15.1-14 (Concurrency and ordering). Overlaps and precedences among work occurrences use interval relations (overlaps, precedes, contains, or within). Implicit "step order" claims are not admitted as performed-work evidence.

CC-A15.1-15 (Cross-context evidence). If a work occurrence is accepted in multiple contexts, either re-judge it in each context or provide bridge relations that map acceptance criteria, units, and role-assignment relations. Name identity alone does not carry cross-context acceptance.

CC-A15.1-16 (Method-description source changes during work). If the method-description version changes mid-run, split the work into episodes bound to respective method-description source editions, or record an explicit method-description override event in the judgement context. Silent substitution lowers the work claim.

CC-A15.1-17 (Distributed performers). If multiple U.RoleAssignment values jointly perform the same top-level work occurrence, either designate a lead U.RoleAssignment with concurrent parts, or model the top-level occurrence as a parent work with child work occurrences per U.RoleAssignment.

CC-A15.1-18 (Logs are evidence, not work by themselves). Logs and telemetry evidence a work occurrence only after they are bound to method-description source when current, performer, time window, affected referent, and judgement context.

CC-A15.1-19 (Affected referent). Each U.Work claim names at least one affected referent, such as asset, product, batch, dataset, or document, through affected -> {...}.

CC-A15.1-20 (State-change witness). Each U.Work claim carries either explicit pre-state and post-state references on the declared state-plane or a delta predicate evaluable on evidence. A no-op run is flagged as such.

CC-A15.1-21 (Affected-referent declaration vs. record handling). A run whose only effect is copying or reformatting records qualifies as U.Work only when the judgement context declares those records to be the product referent, such as data-product manufacture.

CC-A15.1-22 (Executed-within declaration). Each U.Work claim names executedWithin -> U.System or executedWithin -> U.SubSystem; when that system differs from the asset of change, keep affected explicit.

CC-A15.1-23 (Compositionality of delta). For composite work, the parent effect is the declared composition of child effects under the same overlap policy as Gamma_work.

CC-A15.1-24 (No new claims on publication views). MVPK views for U.Work project the declared work-occurrence claim; they do not add properties or claims. Numeric or comparable content names unit, scale, reference-plane, and EditionId pins; work-publication views do not use "signature" for these publication pins.

CC-A15.1-25 (No Gamma leakage). Publication views reference Gamma operators and policies by id when showing aggregates. They do not encode aggregation semantics in prose or imply defaults. Gamma lives in Part B; views carry pinned references only.

CC-A15.1-26 (No input-output re-listing). Publication views do not restate method-description input and output lists; they publish presence pins and source references only under the publication-use pattern governing that view.

CC-A15.1-27 (Comparator ordering and return sets). Across-run comparison presented on a U.Work publication view uses a declared ComparatorSet (map-then-compare), returns sets when order is partial, and lowers hidden scalarization or ordinal-mean claims.

CC-A15.1-28 (Comparator and transport pins). Numeric or comparable acceptance or KPI claims on a U.Work publication view pin ComparatorSet.edition, comparator-spec edition, and, where conversions occur, TransportRegistry.edition with the selected transport policy ids. Bridge ids carry cross-context or cross-plane reuse; penalties affect the reliability relation only.

CC-A15.1-29 (Telemetry-reference pins, when applicable). If a work occurrence feeds G.11 or QD and OEE portfolios, the evidence relation cites the telemetry, archive, and policy references declared by the governing comparison, archive, evidence, or refresh pattern. Illumination remains report-only telemetry unless a governing comparison, archive, or selection pattern promotes that use.

#Temporal & Aggregation Semantics (normative operators & invariants)

#Temporal coverage Γ_time

• Input: a finite set S of Work instances or Work parts.

• Output: either (a) the union of their intervals, or (b) the convex hull [min t_start, max t_end]—as declared by context and KPI.

• Invariants:

  • Idempotent: Γ_time(S ∪ S) = Γ_time(S)
  • Commutative: order of elements irrelevant
  • Monotone: if S ⊆ T then coverage(S) ⊆ coverage(T) (for union) or hull(S) ⊆ hull(T) (for hull)

• Usage guidance:

  • Use union for utilization and availability (how much clock time the asset was busy).
  • Use hull for lead time and cycle time (elapsed from first touch to last release).
  • Manager’s tip: Write the choice near the KPI; many disputes are just a hidden union‑vs‑hull mismatch.

#Resource aggregation Γ_work

• Input: a finite set S of Work instances or parts with resource ledgers.

• Output: an aggregated ledger (materials, energy, machine‑time, money, tool wear) with explicit overlap policy.

• Invariants:

  • Additivity on disjoint parts: if intervals and resources are disjoint by policy, totals add.
  • No double‑count: overlapping costs follow the declared policy (e.g., count once at parent).
  • Traceability: each aggregated figure is reconcilable to contributing Work IDs.

• Typical policies:

  • Parent‑attribution: shared fixed costs at parent; variable costs at children.
  • Pro‑rata by wall‑time: split overlaps by relative durations.
  • Driver‑based: allocate by a declared driver (e.g., CPU share, weight, priority).

#Cross-Context Checks (MethodDescription, RoleAssignment, and Work)

When a Work is recorded, perform these three quick checks:

1. Method-description context check. Does methodDescriptionRef refer to a MethodDescription defined in the judgement context, or bridged to it, when that source is current?

   • If no, the Work is out‑of‑context; either change context or add a Bridge.

2. RoleAssignment interval and context check. Does performedBy cover the work interval in the same context, or is it bridged?

   • If no, the Work is unassigned for that context; remedy via a covering U.RoleAssignment or a policy exception.

3. Standard-Outcome Check. Do the Work inputs, outputs, and metrics satisfy the acceptance criteria from the method-description source or declared standard as interpreted in that context?

   • If no, the Work fails or is “conditionally accepted” per context policy.

Manager’s mnemonic: Context, assignment, Standard → CAC. Fail any → the Work is not acceptable here (perhaps acceptable elsewhere).

#Anti‑patterns (and the right move)

• "The log is the performed run." Dumping telemetry without occurrence references (method-description source when current, performer, time window, affected referent, context) -> Not Work. Create a work-occurrence record and link the log as evidence.
• Record-only transforms. ETL or replication of records with no declared affected referent (product or dataset as product) -> Not Work in this context; either declare the dataset as the product referent or move it to U.WorkPlan or the relevant operations pattern.
• Silent cross‑context acceptance. “Ops accepted it, so audit accepts it.” → Add a Bridge or re‑judge in audit context.
• Method-description edition drift in mid-run. Swapping SOP v5->v6 without recording -> split into episodes or record method-description override.
• Budget on the method. Charging costs to Method or Role -> Book only to Work; keep estimates in method descriptions or plans.
• Part ambiguity. Mixing retries, episodes, and operational parts with no declared relation → Choose and declare the part relation.
• Union-hull confusion. Changing KPI coverage silently between reports -> declare Γ_time policy per KPI.
• Double‑count in overlaps. Summing child and parent resource ledgers → Declare and apply an overlap policy.

#Existing work-log repair moves

1. Backfill links. For existing logs, create work-occurrence records and attach enactsMethod, methodDescriptionRef when current, and performedBy.
2. Name the context. Pick the judgement context explicitly; add Bridges if multiple contexts accept.
3. Record the episode policy. Decide when an interruption keeps identity or forces a new run.
4. Choose Γ_time per KPI. Put "union" or "hull" in the KPI definition so disputes expose the coverage policy instead of hiding it.
5. Set an overlap policy. Write one sentence on how shared costs are allocated; apply consistently.
6. Pull plans out. Move calendars to U.WorkPlan; let Work record performed values.
7. Parameter blocks. Make parameters explicit and bind them at start; root-cause analyses become easier.

#Consequences

#SoTA Alignment

SoTA alignment rule. A source tradition counts here only when it preserves the local U.Work distinction: dated occurrence, role-assigned performer, enacted method, method-description source when current, time window, affected referent, resources, outcome, and evidence-provenance relation. Historical occurrence modeling is used as lineage only when a current standard or current practice still needs the same distinction.

#Relations

• Builds on: A.1 Holonic Foundation; A.1.1 U.BoundedContext; U.System; A.2 U.Role; A.2.1 U.RoleAssignment; A.2.2 U.Capability; A.3.1 U.Method; A.3.2 U.MethodDescription.
• Coordinates with: A.15 Role-Method-Work Alignment (the "four-slot grammar"); B.1 Gamma (aggregation) for resource and time operators; E.10 and E.10.ARCH for source cues such as process, workflow, activity, schedule, algorithm, solver, and procedure; A.10, B.3, E.17, and A.15.4 when evidence, assurance, publication-use, or source-restoration claims are being made.
• Informs: reporting and KPI patterns; assurance and evidence patterns (Work as the reference occurrence for audits); scheduling patterns (U.WorkPlan -> U.Work deltas).

#Didactic quick cards

• What is Work? How it went this time → dated, resourced, accountable.
• Four-slot grammar: Who? RoleAssignment. Can? Capability. How? Method or MethodDescription. Did? Work.
• CAC checks: Context (judgement), assignment (covering U.RoleAssignment), Standard (acceptance criteria).
• Roll‑ups: Γ_time = union (utilization) or hull (lead time); Γ_work with a declared overlap policy.
• Episodes vs retries: same run split vs new run; write the policy.
• Resource honesty: performed values booked only to Work; estimates belong in method descriptions or plans.

#P2W Performed-Work Use Relation

When E.18.1 reaches performed work, U.Work states the dated occurrence: performer, method-description source, parameters, resources, time window, pre-state, post-state, outputs, outcome, and audit trace.

A U.Work occurrence may cite a U.WorkPlan or SlotFillingsPlanItem as planned baseline. The performed-work record states launch values, performed values, substitutions, variance, telemetry, and result-related records; comparator, transport, PrincipleFrame, evidence, assurance, and gate claims are separate current relations when the carry-through record names them.

#Lowering, Repair, and Refresh Conditions

Lower a candidate U.Work claim when performer, enacted method, method-description source when current, time window, executedWithin, affected referent, parameter bindings, resources, outcome, or state-change witness cannot be named at the granularity required by the next work move. The acceptable lowered record is a plan note, evidence note, source-gap note, source-restoration request, or method-description reference, not a backdated work occurrence.

Repair the work record when a subsequent source changes the work interval, performer, role assignment, enacted method, method-description edition, parameter binding, resource ledger, outcome, affected referent, state-plane reference, pre-state reference, post-state reference, overlap policy, or aggregation policy. Repair only the changed relation: do not rewrite the method when only evidence changed, do not rewrite evidence when only work time changed, and do not convert a plan or source-restoration request into work.

Refresh before cross-context acceptance, aggregation, comparison, result measurement, release reliance, gate use, evidence use, assurance use, QD or OEE archive use, or P2W carry-through use. If the claim being made after refresh is no longer performed work, use the governing pattern for that relation and keep only the returned U.Work reference here.

#A.15.1:End

#U.WorkPlan

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

At a glance. Use U.WorkPlan when the current claim is intended work: horizon, planned window, intended role requirements, planned constraints, resource budgets, dependencies, acceptance targets, and baselines for subsequent variance against performed U.Work.

Use this when. Use this pattern when a schedule, calendar, rota, Kanban ticket, Gantt bar, shift plan, rollout plan, reservation, planning cue, or P2W preparation note is being treated as a method, method description, performed work, evidence, approval, gate result, publication cue, query-plan representation, or database query-optimizer representation. U.WorkPlan is an episteme for intended U.Work; it can coordinate action, but it does not make work happen.

First output. One plan record or PlanItem naming horizon, cadence, target U.Method, method-description source when current, planned window, intended role requirements or proposed U.RoleAssignment, planned constraints, resource budgets, dependencies, acceptance targets, planned baseline, and the variance relation expected when U.Work occurs.

First-use checks.

1. Name the intended work occurrence or work family that needs planning.
2. Recover target method, method-description source when current, planned window, role requirements, planned resources, dependencies, acceptance targets, baseline, and context.
3. Decide whether the encountered record, cue, or plan element is a U.WorkPlan, a method description, performed U.Work, a SlotFillingsPlanItem, evidence, gate claim, source-restoration case, publication-use cue, or declarative representation.
4. Declare PlanItem decomposition, dependency relation, and planned-baseline policy before using the plan for coordination or variance.
5. When work occurs, connect the U.Work record back to the PlanItem and record variance rather than rewriting the plan as if it had happened.

Ordinary use. For simple coordination, a compact PlanItem with intended method, window, role requirement, resource budget, dependency, acceptance target, and baseline is enough.

Reliance-bearing use. Use the fuller WorkPlan record when cross-role coordination, budget reservation, delivery commitment, gate preparation, audit expectation, cross-context acceptance, release preparation, evidence-reference notes, source-currentness requests, or P2W carry-through depends on the plan.

Stop condition. Stop once the intended work is coordinated at the needed granularity or the encountered record, cue, or plan element is assigned to method, method description, performed work, evidence, gate, publication-use, declarative-representation, or source-restoration use without claiming to be a plan.

What goes wrong if missed. Teams treat calendars, tickets, reservations, or rollout notes as if work already happened, or treat a plan as method, evidence, gate result, approval, or publication authority.

What this buys. One intended-work record that keeps horizon, window, intended role requirements, constraints, budgets, dependencies, acceptance targets, baseline, and subsequent variance against performed U.Work inspectable.

Not this pattern when. Not this pattern when the current claim is a dated performed work occurrence (A.15.1), a SlotFillingsPlanItem (A.15.3), a visible source cue needing work-relevant restoration (A.15.4), a method (A.3.1), a method description (A.3.2), evidence or assurance (A.10 or B.3), a gate or constraint decision (A.20 or A.21), publication-use behavior (E.17), or a declarative representation overread as a work-control or method claim (C.2.P.DR).

#Context (plain‑language motivation)

Operations happen in time. Even with perfect roles, abilities, and methods, nothing ships unless teams decide when and by whom concrete runs are intended to happen, under what constraints and budgets. Teams need a first-class concept for plans and schedules that does not get confused with:

• the semantic “way of doing” (that is U.Method),
• the written recipe (that is U.MethodDescription),
• the performed work occurrence (that is U.Work), or
• the state laws (that is U.Dynamics).

U.WorkPlan is that missing intended-work record.

#Problem (what breaks without WorkPlan)

1. “Workflow = schedule” conflation. Flowcharts or code are used as calendars; resource clashes and SLA misses follow.
2. Plan and run blur. Gantt bars or Kanban tickets are reported as if the work already happened; audits and costing degrade.
3. Specification and time leakage. People and calendars creep into MethodDescriptions; reuse and staffing agility collapse.
4. No variance model. Without planned baselines, deviations in time, cost, and quality cannot be explained or improved.
5. Structure entanglement. BoM and org charts get baked into “process” views; plans become brittle and unmaintainable.

#Forces (what the definition balances)

#Solution - U.WorkPlan as the time-bound intention for U.Work

#Definition

U.WorkPlan is an U.Episteme that declares intended U.Work occurrences over a horizon, with planned windows, dependencies, intended performer requirements as U.Role values or proposed U.RoleAssignments, resource budgets and reservations, and acceptance targets within a U.BoundedContext.

Strict distinction (memory aid): Method = how in principle. MethodDescription = how it is written. WorkPlan = when, by whom in intent, under which constraints. Work = how it went this time.

#PlanItem values (what a WorkPlan is made of)

A U.WorkPlan contains PlanItem values (think: scheduled tasks or operations), each of which typically states:

1. Target Method and specification — the Method to be enacted and the MethodDescription intended for enactment.
2. Planned window — e.g., earliest start and latest finish, timebox, recurrence (cron-like), blackout periods.
3. Role requirements — required U.Role values, not people; optional proposed U.RoleAssignments if pre-assignment is admitted in the context.
4. Capability thresholds — minimal abilities required of the performer, checked for the performed-work interval.
5. Resource budgets and reservations — planned energy, materials, machine windows, money, and reservations on assets.
6. Dependencies — precedence, overlap permissions, required gate references, and required approval references.
7. Acceptance targets — quality windows and SLA targets to be judged when Work completes.
8. Location and asset constraints — where the run is expected to take place.
9. Links to Service promises (if any) — external commitments that this plan aims to satisfy.

Didactic guardrail: No logs or actuals belong in a WorkPlan; no step logic or solver internals either - that is the Method or MethodDescription.

#Clear distinctions for schedule, process, and workflow wording

Schedule-word guard. Schedule-like words do not determine the kind by themselves. Use U.WorkPlan only when intended work, horizon or window, role constraints, resource constraints, dependencies, acceptance target, and baseline are current; otherwise recover method, method description, work, evidence, gate, publication-use, or declarative-representation claims separately.

#Plan mereology (composition of plans ≠ composition of methods or runs)

Keep three separations crystal‑clear:

• Method composition (design-time semantics) -> produces new Methods.
• Work composition (run-time occurrences) -> produces parent and child runs with overlaps and episodes.
• Plan mereology (epistemic structure) -> organizes PlanItem values for coordination (phases, sprints, shifts), with precedence and resource reservations.

Common relations among PlanItem values:

• Precedes_pl or DependsOn_pl — start and finish constraints and gates.
• MayOverlap_pl or MutuallyExclusive_pl — allowed overlaps versus exclusive windows.
• Refines_pl — a child PlanItem tightens windows and budgets of a parent.
• Alternative_pl — planned alternatives (e.g., backup rig, backup team).

Didactic rule: A PlanItem does not force an identical Work shape; its relation to performed Work is via fulfilment and variance (see §6).

#How WorkPlan Meets Work (Fulfilment and Variance)

When reality happens, each U.Work may:

• Fulfil a PlanItem — link plannedAs → PlanItem.
• Partially fulfil — multiple Work instances share one PlanItem (e.g., split run), or one Work fulfils several PlanItem values (e.g., consolidated batch).
• Deviate - occur with method or method-description substitution, different window, different performer, or policy exception.
• Be unplanned — Work with no PlanItem (emergency or ad hoc); record it as unplanned when that relation matters for variance, audit, or improvement.

Variance dimensions the plan expects to report on:

• Schedule variance (Δt): early or late versus planned window.
• Cost variance (Δc): actual resource spend vs budget.
• Scope variance: different Method or MethodDescription than planned (with justification).
• Quality variance: acceptance verdict vs target.
• Assignment variance: intended versus actual U.RoleAssignment.

Manager’s view: A plan that cannot report variance is a calendar picture, not a management tool.

#What a good WorkPlan states (review checklist)

Use this as a human-facing checklist (not a rigid schema):

1. Horizon & cadence (e.g., “W36 surgeries, daily ETL”).
2. PlanItem values with: target Method and MethodDescription, planned windows, dependencies.
3. Role requirements (U.Role values) and intended assignments (optional, context-admitted).
4. Capability thresholds and safety envelopes.
5. Resource budgets and reservations on assets.
6. Acceptance targets (SLA and quality windows).
7. Bridges if plan spans multiple contexts (operations, audit, or regulatory).
8. Baseline and version plus change notes (so variance is attributable).
9. Policy pointers (episode policy, overlap policy for Work roll‑ups if needed for KPIs).
10. Exception relation (how ad hoc or emergency work is related back to planning, if that relation is needed).

#Archetypal grounding (parallel domains)

#Hospital OR day plan (shift rota + cases)

• WorkPlan: OR_DayPlan_2025‑08‑12.
• PlanItem values: Case_1_Appendectomy, Case_2_Hernia, with windows, context assignments, and surgeon U.Role values; anesthetist intended U.RoleAssignment provided.
• Budgets: OR time blocks, consumables envelopes.
• Fulfilment: Each surgery Work links to its PlanItem; variances computed (over-run time, substitutions).

#Fab maintenance weekend (asset reservations)

• WorkPlan: Fab_Maintenance_W36.
• PlanItem values: Tool_42 chamber clean, Tool_13 calibration; MutuallyExclusive_pl with production windows.
• Reservations: nitrogen, DI water, metrology window.
• Fulfilment: Actual clean Work happens earlier; variance logged as early with cost underrun.

#Data‑center rollout (multi‑context plan)

• WorkPlan: DC_Rollout_Phase‑2.
• Bridges: Ops context ↔ Security Audit context (different acceptance targets).
• PlanItem values: Deploy Service A, Pen-test A; dependencies across contexts.
• Fulfilment: Deployment Work passes ops targets; audit Work passes after the deployment work, with variance reported per context.

#Scope Declaration and Rationale

• Applicability: Use the same intended-work test for coordination, budgeting, architecture planning, teaching examples, and source or evidence questions; when the current claim is performed work, evidence, assurance, publication-use, source restoration, or declarative representation, apply the governing pattern for that claim.
• Scope declaration: Universal; meanings of windows, budgets, and permissions are context-local via U.BoundedContext.
• Rationale: Elevates planning and scheduling to a first-class episteme that coordinates Methods, U.RoleAssignments, and Work without conflation.

#Conformance Checklist

#Common Anti-Patterns and How to Avoid Them

• Plan-as-actual. Do not treat a Gantt bar, Kanban ticket, shift rota, or calendar booking as performed work; create or cite the U.Work occurrence when work happens.
• Workflow-as-schedule. Do not treat a method description or flowchart as a plan; make a U.WorkPlan only when intended windows, constraints, role requirements, and baselines are current.
• Assignment-by-plan. Do not treat an intended performer in the plan as a U.RoleAssignment satisfying the governing role, holder, and bounded-context constraints for the work interval; validate assignment when the work occurrence is prepared or recorded.
• Budget-as-cost. Do not book planned budgets as actual resource use; actuals belong to U.Work.
• Plan-shape overreach. Do not force performed work to match plan decomposition; use fulfilment and variance relations.
• Evidence-note-as-claim. Do not treat evidence-reference notes, gate-preparation notes, or source-currentness requests as evidence, gate passage, assurance, or release permission.

#Consequences

#SoTA Alignment

#Relations

• Builds on: A.15 Role-Method-Work Alignment, A.15.1 U.Work, A.2.1 U.RoleAssignment, U.Method, and U.MethodDescription.
• Coordinates with: A.15.3 for SlotFillingsPlanItem values, A.15.4 for work-relevant source restoration, A.10 for evidence-provenance relations, B.3 for assurance, A.20 and A.21 for gates and constraint decisions, and E.17 for publication-use questions.
• Used by: P2W carry-through when principle-to-work reasoning reaches WorkPlanning and keeps plan, performed work, evidence, gate, and result-measurement relations separate.

#P2W WorkPlanning Use Relation

When E.18.1 reaches WorkPlanning, U.WorkPlan states intended work occurrences, planned windows, intended role requirements, planned constraints, resource budgets, acceptance targets, evidence-reference notes, source-currentness requests, and PlanItem values.

If the same P2W source material also makes a performed-work, launch-value, evidence, gate, result, measurement, publication-use, source-restoration, or refresh claim, write that meaning as a separate current relation before using the plan.

#Launch-Value Boundary For P2W

For P2W use, U.WorkPlan may state planned values, planned fillers, constraints, reservations, intended performers, and evidence-reference notes. Launch values are finalized only at performed-work entry under the current gate relation and performed-work pattern and are recorded with the performed U.Work and related gate and provenance records when current.

#Lowering, Repair, and Refresh Conditions

Lower a candidate U.WorkPlan claim when horizon, planned window, target method, method-description source when current, role requirement, planned constraint, resource budget, dependency, acceptance target, or baseline cannot be named at the granularity required by the next planning move. The acceptable lowered result is a planning cue, method-description note, source-gap note, source-restoration request, publication-use cue, declarative-representation note, or evidence-reference note, not a conforming WorkPlan.

Repair the WorkPlan when a subsequent source changes the intended method, planned window, role requirement, planned resource budget, dependency, acceptance target, baseline, version, bridge, or exception policy. Repair the plan; do not rewrite performed U.Work unless the work record itself changed, and do not make the repaired plan into evidence that the work occurred.

Refresh before relying on a WorkPlan for cross-context coordination, budget reservation, release preparation, gate preparation, evidence-reference use, performed-work entry, result measurement, or P2W carry-through. If the claim being made after refresh is performed work, evidence, assurance, gate passage, publication use, declarative representation, or source restoration, use the governing pattern for that relation and keep only the returned WorkPlan relation here.

#A.15.2:End

#SlotFillingsPlanItem

Tech-name: SlotFillingsPlanItem Plain-name: planned slot-fillings baseline item Short code: SFPI Pattern type: Definitional WorkPlanning pattern Status: Stable Normativity: Normative unless explicitly marked informative Placement: Part A -> A.15 work family Builds on: A.15.2 U.WorkPlan, A.15.1 U.Work, A.6.5 U.RelationSlotDiscipline, E.10.D2, E.17, E.18.1, and E.20 Used by: P2W work-planning slices, suite or kit planned baselines, Part G planned-baseline references, and performed-work variance records One-line purpose: name one planned baseline item that states which planned fillers are intended for which SlotKinds of one slot-bearing description before performed work occurs.

At a glance. Use SlotFillingsPlanItem when a U.WorkPlan needs more than a date, budget, or intended method: it needs a reproducible planned baseline saying which planned fillers are intended for one slot-bearing description's SlotKinds.

Use this when. Use this pattern when a P2W or work-planning slice needs planned references, policy pins, method-description refs, edition pins, evidence-reference pins, guard-preparation refs, or crossing-policy refs to stay fixed before performed U.Work.

First output. One SlotFillingsPlanItem naming exactly one target_slot_bearing_description_ref, one bounded_context_ref, the EntityOfConcern under planning, a time selector or time rule, authoritative planned-filling rows, and any guard-preparation, evidence-reference, edition, or crossing-policy refs needed before performed work.

Working use order.

1. Confirm that the current claim is a planned baseline inside a U.WorkPlan, not the slot-bearing description itself and not performed work.
2. Name the target slot-bearing description and use its SlotSpecs from the governing description pattern, with A.6.5 slot discipline.
3. Name the EntityOfConcern under planning and the bounded context; add a grounding holon only when the current claim needs one.
4. Write planned-filling rows from SlotKind to planned filler, with ByValue or concrete RefKind mode and edition pins when reproducibility depends on them.
5. Keep projections, views, evidence-reference pins, guard-preparation refs, and crossing-policy refs as secondary references. They do not add rows, create evidence, pass a gate, or finalize launch values.

Ordinary use. For a minimal baseline, use context, time selector, target slot-bearing description, EntityOfConcern ref, and planned-filling rows.

Reliance-bearing use. Use the fuller record when reproducibility, launch-guard preparation, crossing expectations, suite or kit reuse, Part G universalization, publication-view projection, or P2W carry-through depends on the baseline.

Stop condition. Stop once the planned rows are explicit enough for the work-planning move, or lower the claim to a plan cue, source-gap note, relation governed by another FPF pattern, or blocked kind-definition gap without claiming a conforming planned baseline.

What goes wrong if missed. Teams hide planned choices in mechanism prose, suite descriptions, generated cards, "latest" references, local checklists, or execution logs. Later nobody can tell what was planned, what was performed, which edition changed, or which variance belongs to performed work.

What this buys. A small planned-baseline record that lets later performed work cite the intended slot fillings and record variance without rewriting the plan after the fact.

Not this pattern when. Not this pattern when the current claim is the slot-bearing description itself (A.6.5 plus the governing description pattern), a mechanism definition (A.6.1 or E.20), a performed work occurrence (A.15.1), an ordinary work plan without slot-filling rows (A.15.2), evidence or assurance (A.10 or B.3), a gate or constraint decision (A.20 or A.21), publication-use behavior (E.17), or a declarative representation overread as work control (C.2.P.DR).

#Context

A.15.2 can already say that work is planned. Some plans also need to freeze a more specific relation: "for this planned work, this slot-bearing description will use these planned fillers in these SlotKinds under this bounded context and time rule."

That extra relation is not the target description, not the mechanism, not a publication view, and not the later performed work. It is a plan item inside work planning. SlotFillingsPlanItem gives that relation a stable place.

Typical situations:

• a CHR or CG-frame plan chooses comparator specs, normalization methods, indicator policies, or guard refs before work;
• a mechanism-suite plan chooses which suite description, method-description edition, or policy ref will be used later;
• a QD or archive plan fixes descriptor and distance-definition editions before selection work;
• a refresh or parity plan cites planned refs so later performed work can record variance rather than silently changing the plan.

#Problem

Without an explicit SlotFillingsPlanItem, six failures recur:

1. Plan and performed-work blur. Planned fillers get treated as launch values or run-time actuals.
2. Slot drift. A SlotKind's meaning changes because the target description edition changed, but the plan still reads as if it meant the old description.
3. Implicit latest. Source text says "use latest" or "current best" without a time selector or pinned edition.
4. View becomes authority. A card, dashboard, or generated view becomes the de facto place where planned rows live.
5. Mechanism prose hides planning. Suite or mechanism text quietly carries chosen fillers even though those choices vary by plan instance.
6. Variance disappears. After work happens, the plan is edited to match the performed work, erasing the gap that audit or improvement needs.

#Forces

#Solution

#Definition

SlotFillingsPlanItem is a kind of U.WorkPlan.PlanItem whose content is one planned slot-filling baseline for one slot-bearing description in one bounded context.

It is:

• produced inside work planning;
• tied to one target description episteme that supplies SlotSpecs;
• pinned enough to replay what was planned;
• cited later by performed U.Work when variance, substitutions, launch values, telemetry, or result records are written.

It is not:

• the target slot-bearing description;
• a MechanismDefinitionRef;
• a gate decision, evidence item, assurance result, publication truth, or performed-work occurrence;
• a second slot ontology beside A.6.5.

#Core fields

A conforming SlotFillingsPlanItem states these fields when the corresponding claim is current:

1. Plan identity

   • plan_item_id
   • kind = SlotFillingsPlanItem
   • work_plan_ref
   • optional plan_item_edition

2. Target slot-bearing description

   • target_slot_bearing_description_ref
   • The target is a Description episteme that declares SlotSpecs, such as a suite description, kit description, method-description family, or other description governed by its own pattern.
   • Do not target MechanismDefinitionRef directly. If a mechanism-level baseline is needed, introduce or cite a description that exposes the slots being planned.
   • When the target description's SlotSpecs are edition-sensitive, the target ref is edition-pinned.

3. EntityOfConcern and context

   • entity_of_concern_ref
   • bounded_context_ref
   • optional grounding_holon_ref when the EntityOfConcern is not itself a holon and the current comparison or reference-plane claim needs grounding;
   • optional reference_plane_ref only when the governing measurement, CHR, or comparison pattern defines that field.

4. Time selector or time rule

   • time_selector_ref or time_rule_ref
   • Use this when "current", "latest", reproducibility, comparability, launch preparation, or source-currentness matters.
   • When time is required, use exactly one of the two forms; both-present and both-absent baselines are nonconforming.

5. Planning scope refs

   • optional cg_frame_ref, p2w_carry_through_ref, publication_scope_ref, suite_ref, or kit_ref when those relations are current;
   • these refs locate the planned baseline, but they do not add planned rows by themselves.

6. Guard-preparation refs

   • optional expected guard or policy refs, such as compare-guard or launch-guard preparation refs;
   • these refs name what later work or gate checks should be prepared to use;
   • the PlanItem records preparation, not the guard result.

7. Evidence-reference pins

   • optional concrete pin refs naming where evidence is expected to be placed or cited later;
   • a pin ref is not evidence and does not create evidence sufficiency.

8. Crossing-preparation refs

   • optional refs for expected cross-context or cross-plane support, such as BridgeCard refs, policy-id refs, reference-plane refs, or already-published CrossingBundle baseline refs;
   • these refs state expected crossing support only;
   • they are not crossing witnesses, do not embed CL/Phi/Psi tables, and do not claim that a crossing occurred.

9. Authoritative planned-filling rows

   • planned_fillings[], each row with:
     • row_id;
     • slot_kind, taken from the target description's SlotSpecs;
     • planned_filler, written ByValue or ByRef with a concrete RefKind;
     • optional edition_pin;
     • optional planning_note.
   • If the target SlotSpec is single-valued, there is at most one row for that SlotKind.
   • If both a row and its referenced filler carry edition pins, they agree or the baseline is nonconforming.

10. Derived projections