#Cluster A.V - Constitutional Principles of the Kernel

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

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

#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 lanes that make claims about it; specification is a gated use or refinement of a Description episteme, not a third peer member of this distinction).

It harmonizes A.12 (External Transformer), A.13 (Agential Role & Agency Spectrum), A.14 (Advanced Mereology), A.15 (Role-Method-Work Alignment), C.2.1 (U.EpistemeSlotGraph), 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; only systems can enact behaviour.
• Externalization (A.12). Every change is performed by a system bearing TransformerRole across a boundary; there is no “self‑magic”.
• Quartet backbone (A.3, A.15). We separate MethodDescription (description), Method (abstract way-of-doing), Capability (a system's ability or envelope to enact a Method under conditions), and Work (run‑time occurrence), with the system bearing TransformerRole as the acting side.
• Evidence (A.10). Knowledge claims cite Symbol-Carrier Register (SCR) carriers; 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 and lanes)}. 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 exit — 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 exits 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, lanes, records, and carriers remain orthogonal lanes: 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 (behaviour)

• Role (role‑object, mask). A contextual position a holon can bear (A.2, A.15). A role is not behaviour; it is the mask under which behaviour may be enacted. Example: Cooling‑CirculatorRole in a thermal loop.

• Function = behaviour = Method under a role. What a system is described as doing when bearing a role. In Transformer context, this behaviour is a Method (abstract way-of-doing) that a system may have the Capability to enact under conditions and that can be performed as Work (run‑time).

  • Safe rewrite for earlier “Holonic Duality (Substance ⧧ Function)”: Holonic Duality (Substance ⧧ Role). A U.System keeps its identity (substance) while switching roles; each role may entail a Method (abstract way-of-doing), a Capability envelope to enact that Method under conditions, and possible Work (performed occurrence).

Normative guard: Use “Role” for the mask; use “Method” for the abstract way-of-doing, “Capability” for a system ability/envelope to enact a Method under conditions, and “Work” for the performed occurrence. Do not call the role itself a function, and do not define Method as Capability.

#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 SCR carriers 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 — the only holon kind that can bear behavioural roles and enact Method and Work.
• Episteme — cannot act; it is changed via its carriers by a system. Epistemes may bear non‑behavioural roles (e.g., ReferenceRole, ConstraintSourceRole).
• Holon — umbrella term; do not use it where only system is meaningful (e.g., “holon bearing TransformerRole” is invalid; write “system bearing TransformerRole”).

Normative guard: Behavioural roles (including TransformerRole) have domain = system. Epistemes may bear purely classificatory roles only.

#Episteme vs Symbol Carrier (SCR/RSCR)

• Episteme — the knowledge content (claim, model, requirement set).
• Symbol Carrier — the physical or digital carrier for an episteme publication or stored representation (file, volume, dataset item), tracked in SCR; remote sets in RSCR.
• 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.
  • RoleBearerOf — a system is the bearer of a Role.

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 a symbol carrier by the same relation; physical and digital carriers stay in SCR/RSCR (A.10).
• 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 routing. Cross-context or cross-reference-plane reuse cites Bridge id + CL; Phi(CL) and Phi_plane penalties route 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 exits rather than pretending to prove it: use C.29 for the mathematical lens, TGA and P2W where transduction and postulate-theory work supply the required justification, E.18 where a gate crossing is the live relation, or the relevant architecture or TGA pattern where the comparison is about structure, graph, flow, or architecture description.

#Typed describing morphism and specification-use exit (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 exit. 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 bearing TransformerRole enacts Work on the asset; evidence binds to carriers. 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 SCR carriers).
• 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 (SCR id: scr://std/S‑174/2025‑07), printed volume (scr://print/S‑174/2e).
• Role: ReferenceRole in the valve selection activity.
• System bearing TransformerRole: design team’s selection service.
• 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 bear AgentialRole (A.13).
• Safe phrasing: “Team T plays Cooling‑MaintenanceRole and executed 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 Transformer as a system bearing AgentialRole) that used the model; list carriers touched.

3. Triad everywhere — omitting Work entirely. Fix: Add the Work lane: 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 SCR/RSCR ids; tie claims to carriers.

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 stacks (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 exit; 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 quartet in context: system bearing TransformerRole, Role, MethodDescription, Method, Capability, Work, and SCR 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 (Roles), A.3 (Transformer Quartet), A.10 (Evidence & SCR), A.12 (External Transformer), A.14 (Advanced Mereology), A.15 (Role–Method–Work 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 routing), C-cluster (selection and archives) by enforcing EntityOfConcern and Description-episteme boundary, specification-use exit, 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 (E.TGA - GateCrossing 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

“The system bearing TransformerRole ⟨name⟩ plays ⟨Role⟩; it has Capability ⟨C⟩ to enact Method ⟨M⟩ (from MethodDescription ⟨S⟩) and executed Work ⟨W⟩ on ⟨time⟩, citing ⟨SCR ids⟩ as evidence carriers; resources accounted via Γ_work.”

Five binary checks

1. Actor ban: No “actor” token; canonical phrasing present.
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 listed (SCR).
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 masks (e.g., Cooling‑CirculatorRole).
• 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 (C‑4)

“A claim without a chain is only an opinion.”

#Context

FPF is a holonic framework: wholes are built from parts (A.1, A.14), and reasoning travels across scales via Γ‑flavours (B.1). To keep this reasoning honest and reproducible, every published assertion must be evidenced through concrete symbol carriers and well‑typed transformations performed by an external TransformerRole (A.12, A.15). Per A.7, Describe_EoC_DescEp is the describing morphism from EntityOfConcern to Description episteme; specification use is granted only by neighboring pattern governing the claiming gates such as A.6.2, C.2.3, A.21, C.16, E.17, or E.10. Publication makes Description epistemes available through publication forms, faces, units, renderings, or carriers and is not execution. Any physical/digital release, rendering, or upload is Work by an external transformer on carriers, cited in SCR.

Practitioner shorthand:

Claim → (Proof or Test) → Confidence badge …where the proof/test is traceable to real carriers and to an external system/Transformer who executed an agreed method.

This pattern defines the Evidence Graph Referring Standard common to all Γ‑flavours (Γ_sys — formerly Γ_core, Γ_epist, Γ_method, Γ_time, Γ_work) and clarifies: (a) the difference between mereology (part‑whole; builds holarchies) and provenance (why a claim is admissible; does not build holarchies); (b) the run‑time / design‑time separation (A.4) across Role–Method–Work (A.15).

Use this when a model, report, metric, confidence badge, review note, or QL reading is starting to act like evidence but the carrier, transformer, method, time stance, or provenance edge is still implicit. The action is to turn the assertion into a small because-graph: name the claim, name the carriers, name the external transformer role, name the method or work trace, state the time/coverage condition, and attach the resulting evidence edge to the claim rather than to the holon itself.

Useful output: a claim that can answer "because of which carriers, by which transformer, using which method, and when?" without making provenance pretend to be part-whole structure.

#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 actually ran” are conflated.
3. Self‑justifying loops. A holon attempts to evidence itself (violates A.12 externality), producing cyclic provenance and unverifiable conclusions.
4. Source loss during aggregation. As Γ combines parts, some sources “fall out”; later audit cannot reconstruct why a compound claim was accepted.
5. Temporal ambiguity. Time‑series are aggregated without interval coverage or dating source; gaps/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 hooks for proof obligations. Its primary EntityOfConcern is the evidence/provenance path for a claim: carriers, external transformer roles, method traces, work traces, time stance, and evidence edges. 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.

#EPV‑DAG (Evidence–Provenance DAG).

A typed, acyclic graph disjoint from mereology. Node types: SymbolCarrier (a s.System in CarrierRole, A.15), TransformerRole (external Transformer, A.12), MethodDescription (design-time blueprint of a method, A.15), Observation (a dated assertion or result record), s.Episteme (knowledge holon). Edge vocabulary is small and normative: evidences, derivedFrom, measuredBy, interpretedBy, usedCarrier, happenedBefore (temporal), etc. Practitioner view: it is the “because‑graph”: every claim answers “because of these carriers, by this Transformer, using that method, then.”

#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 EPV-DAG, not in the mereology graph.

#A.10:4.3 SCR / RSCR (Symbol Carrier Registers).

Every Γ_epist aggregation SHALL emit an SCR: an exhaustive register of symbol carriers substantively used in the aggregate, with id, type, version/date, checksum, source/conditions and optional PortionOf (A.14) for sub‑carriers. Every Γ_epist^compile SHALL emit an RSCR: SCR specialised to a bounded context (vocabularies, units) with publication‑grade identifiers and hashes. Why this matters: it prevents “lost sources” during composition and underwrites reproducibility without mandating any specific tool.

#A.10:4.4 Scope alignment (A.4) across Role–Method–Work (A.15).

• Design‑time: MethodDescription lives here as an episteme describing U.Method; evidence relations reference what would constitute proof or test for that method.
• Run‑time: Work (actual execution) lives 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.

#A.10:4.5 External TransformerRole (A.12).

The system that produces or interprets evidence is external to the holon under evaluation. If true reflexivity is essential, model a meta‑holon (A.12): the self‑updating holon becomes the object of a meta-holon external transformer (the “mirror”), restoring objectivity.

#A.10:4.6 Γ-flavour hooks (how each flavour evidences).

• Γ_sys (formerly Γ_core): physical properties are evidenced by measurement models, boundary conditions, calibration carriers, and dated observations.
• Γ_epist: always outputs SCR/RSCR; every provenance/evidence node resolves to an SCR/RSCR entry.
• Γ_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 (no unexplained gaps/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 SCR/RSCR.

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 reliance. The evidence path is claim-bound: it evidences a named claim or effect for a 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 and provenance path to source-sensitive cases where displays, credentials, copied text, generated text, dashboards, provenance labels, or attestations are being overread. If the live work occurrence, gate decision, speech act, commitment, or evidence path is already clear, recover and cite that FPF 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 path for routine reliance:

Expanded fields are collected only insofar as they decide the live 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 reviewer names, or sensitive model/data provenance. Redaction does not create source relation; it must preserve enough recoverability for the relying context.

Case repairs:

If the path is incomplete, A.10 returns evidence-path state and source-currentness status, not work or reliance evidence relation for the attempted claim or effect. Valid 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 live P2W class or reliance claim, proceed only with a reversible local probe under an explicit work plan when work is live, or block the unsupported work claim or reliance claim.

Broken-source repair assignment. If the relying actor cannot recover or verify the source path, assign the repair to the accountable project-side responsibility assignment: issuer or performer, verifier or status service, evidence-producing work role assignment or system, gate-decision source, role or 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.

Role prompts for evidence or currentness use:

Repeated missing-source indicator. If the same visible-item family repeatedly returns stale, contested, no-source, or no-currentness A.10 results, record a source-system repair item: 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 path or display needs repair; it is not a reason to make each acting user rebuild the path manually.

Display guidance for evidence and currentness: an evidence or status display should show the claim or effect, carrier, source-maintenance role assignment, reference or link named by value, time window, freshness, relying context, and unsupported action, 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 source-path field, exact carrier, 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 item for instrumentation, source refs, status, currentness, claim-bound source links, credential view, model documentation, data documentation, or provenance and attestation label.

Contestability and redress path: 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, carrier, source-maintenance role assignment, verifier or status source, freshness or revocation source, privacy-minimized evidence ref, safe interim disposition, and review or redress path. A disputed display remains contested until the source-order or currentness question is resolved.

Positive repaired path. When the source path is complete, return the smallest source-backed evidence-use statement: named claim or effect, carrier and source-maintenance role assignment, method trace or work trace, time window, currentness, evidence relation, and the exact action or reliance for which it is admissible. The downstream use is admissible only 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 action, 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 exact governingPatternRef or authoritySourceRef 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 use it can actually make admissible. 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 admissible and non-admissible use, then stop or exit to the governing pattern. It is not a required project review step and does not ask the practitioner to inspect every source-looking item.

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/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 live attempted evidence use, then stop when the bounded evidence relation, admissible use, non-admissible use, and reopen condition are clear. This local section returns the attempted use to 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 admissible use, non-admissible use, window, and reopen condition; threshold reliance exits to the minimum governing pattern only when the B.3 material-reliance threshold is live: behavior, safety, release, compliance, public or protocol behavior, access, resource allocation, people/team status, operational action, or controlled-object regulation would materially change. Plain wording remains ordinary unless it changes admissible use, source relation, evidence, gate, assurance, work, decision, or neighboring-pattern exit.

Cheap stop: if a bounded claim, current carrier, evidence path, window, admissible use, non-admissible use, and reopen trigger are present, and no assurance, gate, work, control-bearing relation, release relation, or B.3 material-reliance threshold is live, 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 reading: 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 live.

Plain move palette: RelianceDisposition=pass means proceed only inside the bounded 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 reading; RelianceDisposition=evidence-needed means ask for the named missing evidence at the named decision point; RelianceDisposition=safety-case-required means return to B.3 because the B.3 material-reliance threshold is live; RelianceDisposition=no-admissible-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/window when live, admissible use, non-admissible 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 live 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/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 situation or source condition being read, 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 real contest/redress: a contest path exists only when the affected party or accountable reviewer 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 items is not enough to change the disposition.

Affected-party contestable minimum: even when raw evidence stays reviewer-only, 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 admissible 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 path.

Worked source-overread slices:

#Causal evidence relation basis in evidence paths

Evidence graph paths used for causal-use claims must carry the C.28-governed CausalEvidenceSupportBasis without redefining causal estimands or causal-use authority.

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 evidence-basis values. Assumption-only and no-evidence-use cases are represented by causal assumptions, support verdict, admissible use, non-admissible use, or abstain in [C.28](/generated/patterns/C.28)/[B.3](/generated/patterns/B.3), not by a second evidence-basis vocabulary.

No non-admissible CausalityLadderRung climb:

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 admissible for bounded model use when model assumptions, validation, admissible use, and non-admissible 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 basis and the relevant [C.28](/generated/patterns/C.28) support references when the claim climbs 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 causal support-basis 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 (SoTA alignment, reader‑friendly)

• 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 EPV‑DAG and SCR/RSCR 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 (no unexplained gaps/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, validity 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, and 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-role 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 admissible-work effect without source relation named by value.

Action result from that cited practice basis: 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, admissible use, non-admissible 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.4 Temporal Duality; A.12 Transformer Externalization; A.14 Advanced Mereology; A.15 Role–Method–Work Alignment.
• Constrains / used by: B.1 (all Γ‑flavours: Γ_sys, Γ_epist, Γ_method, Γ\_time, Γ_work); B.1.1 (Dependency Graph & Proofs).
• Enables: B.3 Trust Calculus (R/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 causal-use question, support basis, identification, realizability, and admissible use and non-admissible use.
• 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, admissible work effect, or admissible reliance effect.

#Migration (practical and brief)

Apply these text edits:

1. Terminology

   • manifest → “Symbol Carrier Register (SCR)”; release manifest → “Release SCR (RSCR)”.
   • creator / observer (as internal evidencer) → TransformerRole (external).
   • “symbol register” (ambiguous) → “Symbol Carrier Register (SCR)”.
   • Keep resource rosters in Γ_work separate from SCR/RSCR.

2. Boilerplate inserts

   • In A.10 (this pattern): retain definitions of EPV‑DAG, SCR/RSCR, and the flavour-specific evidence relations.
   • In B.1.3 (Γ_epist): add the Obligations — SCR/RSCR block (“Γ_epist^synth SHALL output SCR… Γ_epist^compile SHALL output RSCR…”).
   • In B.1.5 (Γ_method): ensure MIC is referenced (Precedes/Choice/Join, guards, exceptions) and run‑time traces reference the MethodDescription they instantiate.
   • In B.1.6 (Γ_work): say “resource rosters are not SCR/RSCR; cite meter/log readings via EPV-DAG.”

#Evidence carriers for quantum-like readings

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?"

Action path:

1. State the minimal state, probe, export, or viability reading 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 still live.
6. Choose the next pattern: stay in A.10 for carrier evidence relation, apply B.3 for assurance claims, apply C.16 for measurement legality, 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 readings, include at least:

Useful outputs:

• a local evidence note when the claim only guides discussion;
• an EPV-DAG / SCR / RSCR 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 LensUseAdmissibilityValue 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 (Contextual Role Assignment): Which provides the universal syntax Holder#Role:Context for defining agents.

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 Agent: The agent is a Contextual Role Assignment of the form System#TransformerRole:Context. This is the cause, the "doer."
• 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 action-guiding 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 lives, 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 the unsupported claim.

Working action spine. Role, method, plan, and work confusion -> separate role, holder, context, method description, intended U.WorkPlan, and actual U.Work -> choose proceed, plan, bounded probe, narrow, hand off, 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 action path.

1. Name the role, holder, and context distinction that is live.
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 being made or effect, or stop.
5. If a visible item is being used by appearance for a work claim, reliance claim, or source-restoration claim, move to A.15.4 Work-Relevant Source Restoration and return here 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 green path. If the required project-side FPF kind and reference named by value is present and its scope and window match the live role, method, plan, or work move, 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 unsupported-claim 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. Open the fuller alignment frame when the item 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 a visible item has 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 live role-method-work question (A.6 or A.6.B), or work-relevant source restoration for a visible item (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 item 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 a visible item 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.

Recognition block vs assurance block. Read At a glance, Use this when, Start here when, First output, Working action path, Admissible-use examples, Alignment frame, First admissible project move, What goes wrong if missed, What this buys, and Not this pattern when as the primary recognition block. Read the entity distinctions, canonical relations, checklist, and relations below as assurance blocks that tighten the same alignment-frame claim; they do not widen the pattern into one single work occurrence, one cue note, one wording pattern, one source-restoration pattern, or one source-side "process" label treated as an FPF object.

#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 live FPF object 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, serving as the ultimate implementation of the Strict Distinction Principle (A.7). It weaves together several foundational concepts into a single, coherent model of how intended work becomes planned and actual U.Work:

• A.2 (Contextual Role Assignment): Provides the Holder#Role:Context structure for assigning roles.
• A.4 (Temporal Duality): Provides the strict separation between design-time and run-time.
• A.12 (External Transformer): Ensures that performed U.Work is attributed to a transformer-bearing system acting under a U.RoleAssignment.

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", and "schedule" are constrained by L-PROC, L-FUNC, and L-SCHED (E-cluster): a workflow cue normally resolves to U.MethodDescription unless the abstract way-of-doing itself is live as U.Method; a schedule cue resolves to U.WorkPlan; what happened resolves to U.Work.

Terminology note (L-ACT). The words action and activity are not normative in the kernel. When a generic "doing" is needed, we use the didactic term enactment (not a type). Normative references must be to U.Method, U.MethodDescription, U.Work, or U.WorkPlan. See lexical rules L-PROC, L-FUNC, L-SCHED, and L-ACT.

#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 that paralyzes decision-making. Generic doing or activity terms must be resolved via L-ACT to U.Method, U.MethodDescription (recipe), U.WorkPlan (schedule), or U.Work (run).

#Forces

#Solution

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 a function but is not the function itself.
• 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 formal assertion Holder#Role:Context that links a specific U.Holon to a U.Role within a U.BoundedContext. This holder-to-role assignment link is what "activates" the requirements associated with a role.

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 live. 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 anyone in the ChefRole must have the Capability to follow the recipes in the cookbook.
• 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 a set of precise, normative relations that form an unbreakable causal chain. The following diagram illustrates this flow from the abstract context down to the concrete execution.

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

    RB -- performedBy --> W
    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 the source is live.
• 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 live.
• 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 (Holder + Role + Context) under which the holder was authorized and responsible for its execution.

#Bounded specialization scouting and CheckpointReturn

When one human-plus-AI pair faces a new task family or candidate solution corridor, 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 should declare one outcome criterion first, enumerate heterogeneous candidate approaches that may satisfy that target, spend a bounded scouting budget or probing budget before any committed approach is chosen, and return 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 should carry:

• 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, hand off, 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 path, 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 guard rails, and evidence path 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/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 asks which project-side FPF kind and reference named by value must be recovered before the encountered item can carry the live work claim, reliance claim, or effect; 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 a P2W chain recoverable may help the team plan work or find the needed source. It does not replace the selected method, U.WorkPlan, performed U.Work, evidence path, gate or decision record, engineering-justification record, or release-reliance 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 live, 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 path 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 the P2W principles-to-work transduction chain 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 contextual-functional entities, 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, a conforming model or use SHALL satisfy the following checks.

#Common Anti-Patterns and How to Avoid Them

• Role-as-part. Do not place U.Role or U.Capability inside structural partOf decomposition; keep them contextual and functional.
• 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 open; 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.
• Visible item 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 live work or reliance claim.

#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 all of its more advanced patterns, from resource management (Resrc-CAL) and decision theory (Decsn-CAL) to ethics (Norm-CAL).

#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 robot or reviewer 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 returned role, method, plan, and work part 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 Implements: A.7 Strict Distinction.
• Builds Upon: A.2 (U.Role), A.2.1 (U.RoleAssignment), A.4 (Temporal Duality), A.12 (External Transformer).
• Is Used By and Provides Foundation For:
  • C.4 Method-CAL: Provides the formal definition of U.MethodDescription and the Gamma_method operator for composing them.
  • C.5 Resrc-CAL: Provides the U.Work entity to which resource consumption is attached.
  • B.1.6 Gamma_work: The aggregation operator for U.Work.
  • B.4 Canonical Evolution Loop: The entire loop is a sequence of U.Work instances that modify MethodDescriptions.
  • A.15.2 U.WorkPlan: plan-run split, baselines and variance against U.Work.
  • C.28 CausalUse-CAL: causal-use admissibility for intervention, counterfactual sampling, target-trial emulation, and causal evidence work; A.15 keeps the role, method, work-plan, and work-occurrence chain.
• Constrains: Any FPF pattern that models method, plan, work occurrence, or overloaded source language around process terms must use this framework to be conformant. It serves as the canonical alignment for contextual enactment in the FPF ecosystem.
• Coordinates with: L-PROC, L-FUNC, and L-SCHED (E-cluster) for lexical disambiguation of source cues such as process, workflow, and schedule.
• Coordinates with: A.15.4 for work-relevant source restoration; A.6, A.6.B, and A.6.C for mixed boundary, policy, API, or schema 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; A.15.1 for release or deployment work occurrence; and E.17.EFP for generated-explanation faithfulness or source-finding.

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

Action path:

1. Name the role, method, and work result before naming any distributed state.
2. State which work traces, records, events, observations, reports, metrics, or role enactments 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 method governance is live, 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 E.18.1 reaches WorkPlanning, 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 live relation. If the live relation 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 live.

#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 live, 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 live 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 returned 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 question under repair is what actually happened: a dated, resource-consuming occurrence enacted by a holder under U.RoleAssignment, inside a U.BoundedContext, with method, time window, parameters, resources, affected referent, result, and evidence kept inspectable.

Use this when. Use this pattern when a plan, method description, schedule, log, telemetry stream, dashboard, approval-looking cue, or result statement is being treated as if it were actual performed work. U.Work is the run-time occurrence; the surrounding records may identify, constrain, evidence, schedule, 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 live, executedWithin, time window, concrete parameter bindings, affected referent, resource ledger, pre-state and post-state anchors or a declared delta predicate, outcome, and the governing U.BoundedContext.

Working action path.

1. Name the candidate occurrence and the work move 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, and outcome.
3. Decide whether the item is actual U.Work, only a plan (A.15.2), only a method or method description (A.15), only evidence for work (A.10), 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 anchors cannot be recovered, lower the claim to a source-gap note, work-evidence note, plan note, or source-restoration request; do not backdate work.

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

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

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

Not this pattern when. Not this pattern when the live object is only a method description, only a plan or schedule (A.15.2), only a slot-filling plan item (A.15.3), only a visible source cue that must be restored before reliance (A.15.4), only evidence or assurance (A.10 or B.3), or only publication-use or representation behavior (E.17, A.7, or the relevant representation pattern).

#Problem Frame

After we have agreed who is assigned (via Role assignment), what they can do (via Capability), and how in principle it should be done (via Method or MethodDescription), we still need a precise concept for what actually happened 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, anchored to a domain referent that actually changes (asset, product, or dataset) - not merely the manipulation of records about that referent. Managers care about Work because it is the place where actual cost, time, defects, and result evidence are booked. Architects care because Work ties plans and specifications to accountable execution.

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

1. Plan and run confusion. Schedules and diagrams get mistaken for "the process," so audits and KPIs become fiction.
2. Specification and run conflation. A method description, code artifact, or SOP is reported as if it were an execution; conversely, logs are treated as recipes.
3. Who and when leakage. People and calendars are baked into specifications; reuse and staffing agility collapse.
4. Resource dishonesty. Energy, money, and tool wear are booked to methods or roles, not to actual runs; 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 live, methodDescriptionRef names the U.MethodDescription used to identify, constrain, or justify the enacted method. Each U.Work is a morphism Δ on a declared state‑plane (StatePlaneRef), mapping ⟨pre‑state, inputs⟩ to ⟨post‑state, outputs⟩ for one or more affected referents.

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

#Core anchors (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. Spec — isExecutionOf → U.MethodDescription (the description actually followed; edition pinned if applicable).
3. Performer — performedBy → U.RoleAssignment (which holder#role:context acted).
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 anchor and post‑state anchor (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; mandatory).
12. Evidence and telemetry (optional) — if the run feeds G.11 refresh or QD and OEE archives, cite PathId or PathSliceId and the active policy-id used for illumination; do not elevate telemetry into dominance without CAL 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/run 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 anchors 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 execution anchors (spec used, 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 specification, 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.
• causedBy or causes — pragmatic causal links (e.g., a rework caused by a failed inspection run).
• 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 caused by a failure in earlier Work; link via causedBy.

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 with parts, the effect of the whole must be the rules-declared composition of the effects of its parts plus any declared overheads and residuals. Composition must align with the overlap rules used by Γ_work (e.g., 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‑10T09:05–11:42.
• Spec: Appendectomy_v5 (MethodDescription).
• Performer: OR_Team_A#SurgicalTeamRole:Hospital_2025 (U.RoleAssignment).
• 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.
• Spec: ETL_v12.bpmn.
• Performer: ETL_Runtime#TransformerRole:DataOps_2025.
• 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 as a path)

• Run: Carnot_Cycle_Run#2025‑08‑09T13:00–13:06.
• Spec: Carnot_Cycle_Spec (MethodDescription with Dynamics model).
• Performer: LabRig_7#TransformerRole:ThermoLab.
• Work identity: the path in state-space traced during the interval; outputs: heat and work tallies.
• Γ_time: straightforward interval; Γ_work: integrates energy exchange; no “steps” required.

#Bias‑Annotation (as in E‑cluster)

• Lenses tested: Prag, Arch, Did, Epist.
• 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 and Role Enactment (A.2.1; A.15) and with 4D extensional thinking, so that costing, quality, and audit rest on runs, not on plans or recipes.

#Conformance Checklist (normative)

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). Every U.Work MUST reference: (a) enactsMethod -> U.Method (the method enacted), (b) methodDescriptionRef -> U.MethodDescription when the source episteme or editioned method description is live, (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). Every U.Work MUST carry 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 anchoring and judgement). A U.Work MUST be judged inside a declared U.BoundedContext (the judgement context).

• By default, the judgement context is the context of the referenced MethodDescription.
• If performedBy references a U.RoleAssignment in a different context, there MUST exist an explicit Bridge (U.Alignment) or policy stating cross-context acceptance. Otherwise, the Work is non-conformant in that context.

CC‑A15.1‑4b (State‑plane anchoring). Each U.Work MUST declare a StatePlaneRef for its Δ‑judgement.

CC‑A15.1‑5 (RoleAssignment validity). The performedBy U.RoleAssignment timespan MUST cover the Work interval. If it does not, the Work is invalid or must be re-judged in a context that allows retroactive assignments.

CC‑A15.1‑6 (Parameter binding). Parameters declared by the MethodDescription MUST have concrete values bound at Work creation or start and recorded with the Work. Defaults in the specification do not satisfy this requirement.

CC‑A15.1‑7 (Capability check). All capability thresholds stated by the Method or MethodDescription MUST be checked against the holder in performedBy at the time of execution (or at defined checkpoints). Violations must be flagged on the Work outcome.

CC‑A15.1‑8 (Acceptance criteria). Success and failure classes and quality grades MUST be determined by the acceptance criteria declared or referenced by the MethodDescription or CG-Spec in the judgment context. The verdict is recorded on the Work.

CC‑A15.1‑9 (Resource honesty). All consumptions and costs (energy, materials, machine‑time, money, tool wear) SHALL be booked only to U.Work (not to Method, MethodDescription, Role, or Capability). Estimates may live in specs; actuals live in Work.

CC‑A15.1‑10 (Mereology declared). If a Work has parts, the chosen part relation(s) must be declared (temporal‑part, episode‑part, operational‑part, concurrent‑part). Ambiguous mixtures are forbidden.

CC‑A15.1‑11 (Γ_time selection). For any roll‑up, the judgement context MUST declare which temporal coverage operator applies: union (utilization) or convex hull (lead time). Silent mixing is prohibited.

CC‑A15.1‑12 (Γ_work aggregation). Aggregation of resource ledgers across Work parts MUST specify an overlap policy (e.g., “attribute shared machine‑time to parent only”) to prevent double‑counting.

CC‑A15.1‑13 (Identity & retries). A retry MUST be modeled as a new Work linked via retryOf. Interruptions that are treated as the same run must be modeled as episodes (resumptionOf) per a context‑declared episode policy.

CC‑A15.1‑14 (Concurrency & ordering). Overlaps and precedences among Work MUST use interval relations (overlaps, precedes, contains, or within). Implicit "step order" claims are not admissible evidence.

CC‑A15.1‑15 (Cross‑context evidence). If a Work is to be accepted in multiple contexts (e.g., regulatory + operational), either: (a) re‑judge it in each context, or (b) provide Bridges that map acceptance criteria, units, and roles; never assume cross-context identity by name.

CC‑A15.1‑16 (Spec changes during run). If the MethodDescription version changes mid‑run, the Work MUST either: (a) split into episodes bound to respective specs, or (b) record an explicit spec override event in the judgement context. Silent substitution is forbidden.

CC‑A15.1‑17 (Distributed performers). If multiple U.RoleAssignments jointly perform the same top-level Work (e.g., multi-agent orchestration), the Work MUST either: (a) designate a lead U.RoleAssignment and list others as concurrent parts, or (b) be modeled as a parent Work with child Works per U.RoleAssignment.

CC‑A15.1‑18 (Logs ≠ Work by themselves). Logs and telemetry are evidence for a Work; they do not constitute a Work unless bound to specification, performer, time window, and judgment context.

CC‑A15.1‑19 (Affected referent). Each U.Work MUST name at least one affected referent (e.g., U.Asset, product, batch, dataset, or document) via affected -> {...}.

CC‑A15.1‑20 (State‑change witness). Each U.Work MUST carry either (a) explicit pre‑state/post‑state anchors on the declared state‑plane or (b) a Δ‑predicate that can be evaluated on evidence. Trivial “no‑op” runs MUST be flagged as such.

CC‑A15.1‑21 (World anchoring vs. record handling). A run whose only effect is copying or reformatting records does not qualify as U.Work unless the judgment context declares those records to be the product referent (e.g., data-product manufacture).

CC‑A15.1‑22 (System anchoring). Each U.Work MUST declare executedWithin -> U.System or executedWithin -> U.SubSystem; if different from the asset of change, keep affected explicit.

CC‑A15.1‑23 (Compositionality of Δ). For composite Work, the parent effect MUST be the declared composition of child effects under the same overlap policy as Γ_work.

CC‑A15.1‑24 (No new claims on publication views). MVPK views for U.Work SHALL NOT add properties or claims beyond the declared work-occurrence claim; numeric or comparable content MUST include unit, scale, reference-plane, and EditionId pins; the term "signature" is banned on work-publication views.

CC‑A15.1‑25 (No Γ leakage). Publication views MUST reference Γ operators and policies by id when showing aggregates; they MUST NOT encode aggregation semantics in prose or imply defaults. Γ lives in Part B; views carry pinned references only.

CC‑A15.1‑26 (No input-output re-listing). Publication views MUST NOT restate method-description input and output lists; publish presence pins and source anchors only (per MVPK §5.4).

CC‑A15.1‑27 (Lawful orders; return sets). Any across-run comparison presented on a U.Work publication view MUST use a declared ComparatorSet (map-then-compare), return sets when order is partial, and forbid hidden scalarization or ordinal means.

CC‑A15.1‑28 (Comparator and transport pins). Any numeric or comparable acceptance or KPI on a U.Work publication view MUST pin ComparatorSet.edition, CG-Spec.edition, and, where conversions occur, TransportRegistry.edition with Φ or Φ^plane policy-ids; Bridge ids are mandatory for cross-context or cross-plane reuse; penalties affect the reliability relation only.

CC‑A15.1‑29 (Telemetry hooks, when applicable). If a Work instance feeds G.11 or QD and OEE portfolios, it SHALL cite PathId or PathSliceId and the active policy-id in its evidence; illumination remains report-only telemetry unless CAL explicitly promotes it.

#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 of the clock time the asset was actually 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 must follow the declared policy (e.g., count once at parent).
  • Traceability: each aggregated figure must be 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 live?

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

2. RoleAssignment context check. Is performedBy's U.RoleAssignment valid in the same context, or bridged?

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

3. Standard–Outcome Check. Do the Work's inputs, outputs, and metrics satisfy the acceptance criteria from the spec 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 process.” Dumping telemetry without binding (spec, performer, context) → Not Work. Create a Work, 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.
• Spec drift in mid‑run. Swapping SOP v5→v6 without recording → Split into episodes or record override.
• Budget on the method. Charging costs to Method or Role → Book only to Work; keep estimates in specs.
• 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.

#Migration notes (quick wins)

1. Backfill links. For existing logs, create Work records and attach isExecutionOf and performedBy.
2. Name the context. Pick the judgement context explicitly; add Bridges if multiple contexts must 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; stop arguing in meetings.
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 actuals.
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 live, time window, affected referent, resources, outcome, and evidence path.

#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 Γ (aggregation) for resource and time operators; E-cluster lexical rules (L-PROC and L-FUNC).
• Informs: reporting and KPI patterns; assurance and evidence patterns (Work as the anchor 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 (valid 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: actuals booked only to Work; estimates live in specs.

#P2W Performed-Work Use Relation

When E.18.1 reaches performed work, U.Work carries 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 carries launch values, actuals, substitutions, variance, telemetry, and result-related records; comparator, transport, PrincipleFrame, evidence, assurance, and gate claims are separate live 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 live, 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 admissible 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 anchor, pre-state or post-state anchor, 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 question under repair is intended work: planned windows, 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, or planned reservation is being treated as a method, actual work, evidence, approval, or gate result. U.WorkPlan is an episteme for intended U.Work; it can coordinate action, but it does not make execution happen.

First output. One plan record or plan item naming horizon, cadence, target U.Method, method-description source when live, 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.

Working action path.

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

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

Reliance-bearing use. Use the fuller WorkPlan record when the plan carries cross-role coordination, budget reservation, delivery commitment, gate preparation, audit expectation, cross-context acceptance, or P2W carry-through.

Stop condition. Stop once the intended work is coordinated at the needed granularity or the encountered item is lowered to method, work, evidence, gate, or source-restoration use without claiming to be a plan.

Not this pattern when. Not this pattern when the live object is a dated performed work occurrence (A.15.1), a plan-item filler (A.15.3), a visible source cue needing work-relevant restoration (A.15.4), a method or method description (A.15), evidence or assurance (A.10 or B.3), a gate decision (A.20 or A.21), or publication-use behavior (E.17).

#Context (plain‑language motivation)

Operations live on time. Even with perfect roles, abilities, and methods, nothing ships unless we decide when and by whom concrete runs should 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 actual execution (that is U.Work), or
• the state laws (that is U.Dynamics).

U.WorkPlan is that missing anchor.

#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 we must balance)

#Solution — the U.WorkPlan as the time‑bound intention to execute Work

#Definition

U.WorkPlan is an U.Episteme that declares intended U.Work occurrences over a horizon, with planned windows, dependencies, intended performers as role kinds 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.

#Plan Items (what a WorkPlan is made of)

A U.WorkPlan contains Plan Items (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 — role kinds required (not people), optional proposed U.RoleAssignments if pre-assignment is allowed in the context.
4. Capability thresholds — minimal abilities required of the performer (checked at run time).
5. Resource budgets and reservations — planned energy, materials, machine slots, money, and reservations on assets.
6. Dependencies — precedence, overlap permissions, gates, and approvals.
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 (lexical sanity for schedule, process, and workflow)

L‑SCHED (lexical rule). In this document, words like schedule, calendar, rota, Gantt, plan point to U.WorkPlan unless explicitly redefined by a bounded context glossary.

#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 Plan Items for coordination (phases, sprints, shifts), with precedence and resource reservations.

Common relations among Plan Items:

• 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 plan item tightens windows and budgets of a parent.
• Alternative_pl — planned alternatives (e.g., backup rig, backup team).

Didactic rule: A Plan Item does not force an identical Work shape; mapping is via fulfilment and variance (see §6).

#How WorkPlan Meets Work (Fulfilment and Variance)

When reality happens, each U.Work may:

• Fulfil a Plan Item — link plannedAs → PlanItem.
• Partially fulfil — multiple Work instances share one Plan Item (e.g., split run), or one Work fulfils several Plan Items (e.g., consolidated batch).
• Deviate — execute with method or specification substitution, different window, different performer (still valid or policy exception).
• Be unplanned — Work with no Plan Item (emergency or ad hoc); must be labeled as such.

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. Plan Items with: target Method and MethodDescription, planned windows, dependencies.
3. Role requirements (kinds) and intended assignments (optional, context‑lawful).
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. Exceptions path (how ad hoc or emergency work is planned after the fact).

#Archetypal grounding (parallel domains)

#Hospital OR day plan (shift rota + cases)

• WorkPlan: OR_DayPlan_2025‑08‑12.
• Plan Items: Case#1 Appendectomy, Case#2 Hernia, with windows, context assignments, and surgeon role kinds; anesthetist intended U.RoleAssignment provided.
• Budgets: OR time blocks, consumables envelopes.
• Fulfilment: Each surgery Work links to its Plan Item; variances computed (over‑run time, substitutions).

#Fab maintenance weekend (asset reservations)

• WorkPlan: Fab_Maintenance_W36.
• Plan Items: Tool_42 chamber clean, Tool_13 calibration; MutuallyExclusive_pl with production slots.
• 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).
• Plan Items: 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.

#Bias‑Annotation (as in E‑cluster)

• Lenses tested: Did, Prag, Arch, Epist.
• 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 live.
• Assignment-by-plan. Do not treat an intended performer in the plan as a valid U.RoleAssignment for execution; validate assignment at run time.
• 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.
• Hook-as-claim. Do not treat evidence-reference hooks, 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 slot-filling plan items, A.15.4 for work-relevant source restoration, A.10 for evidence paths, 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 must keep plan, performed work, evidence, gate, and result-measurement relations separate.

#P2W WorkPlanning Use Relation

When E.18.1 reaches WorkPlanning, U.WorkPlan carries intended work occurrences, planned windows, intended role requirements, planned constraints, resource budgets, acceptance targets, evidence-reference hooks, source-currentness requests, and plan items.

If the same P2W source phrase also carries execution, launch-value, evidence, gate, result, measurement, or refresh meaning, write that meaning as a separate live 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 hooks. 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 live.

#Lowering, Repair, and Refresh Conditions

Lower a candidate U.WorkPlan claim when horizon, planned window, target method, method-description source when live, role requirement, planned constraint, resource budget, dependency, acceptance target, or baseline cannot be named at the granularity required by the next planning move. The admissible lowered result is a planning cue, method-description note, source-gap note, source-restoration request, or evidence-reference hook, 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 actual work, evidence, assurance, gate passage, 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 (planned baseline) Type: Architectural (A) Status: Stable Normativity: Normative (unless explicitly marked informative) Placement: Part A → A.15 (Work & WorkPlanning) Builds on: U.WorkPlan (A.15.2), performed-work occurrence discipline (A.15.1 and E.TGA), Context discipline (E.10.D1), MechSuiteDescription (A.6.7), and publication/view discipline (E.17; views are projections, not places of meaning) Used by: planned-baseline requirements from suites or kits; P2W (selection -> WorkPlanning -> WorkEnactment); Part G universalization Purpose (one line): provide a universal, context-explicit planned baseline that maps a slot-bearing description's SlotKinds to planned fillers, to be consumed by Work enactment where launch values are finalized.

At a glance. Use SlotFillingsPlanItem when a U.WorkPlan needs a planned baseline saying which planned fillers will occupy which SlotKinds of one slot-bearing description before work is enacted.

Use this when. Use this pattern when planned references, policies, spec pins, method-description references, evidence pin refs, or crossing-policy pins must be fixed for a P2W work-planning slice, and the plan must stay distinct from launch values, gate decisions, evidence, and performed work.

First output. One SlotFillingsPlanItem with exactly one target_slot_bearing_description_ref, explicit bounded_context_ref, EntityOfConcern ref, time selector or time rule, authoritative planned-filling rows, and any expected guard, evidence, edition, or crossing pins needed before work enactment.

Working action path.

1. Name the slot-bearing description whose SlotKind set is being filled.
2. Name the EntityOfConcern and grounding holon or reference plane when needed.
3. Name context, time selector or time rule, and any P2W slice or publication scope needed for reproducibility.
4. Fill the authoritative rows by SlotKind, using ByValue or ByRef with concrete RefKinds and edition pins when needed.
5. Keep derived indices, views, guard pins, evidence pins, and crossing pins as projections or expectations; do not turn them into execution, gate, evidence, or launch-value claims.

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

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

Stop condition. Stop once planned fillers are explicit enough for the intended WorkPlanning 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.

Not this pattern when. Not this pattern when the live object is the slot-bearing description itself, a mechanism definition, a performed-work occurrence, a gate decision, a launch-value witness, evidence, assurance, or a publication view. Use the corresponding governing pattern and return here only for the planned slot-filling baseline.

Name and reference discipline (informative)

• Kind reuse: This pattern uses the kind name SlotFillingsPlanItem. It reuses existing Core terms and disciplines (e.g., U.WorkPlan.PlanItem, SlotKind, ValueKind, RefKind, and refMode discipline, edition pinning, U.BoundedContext, and the P2W split between WorkPlanning and WorkEnactment).
• SlotFillingsPlanItem (kind name): keep the suffix PlanItem to preserve the WorkPlanning placement. Do not mint aliases like SlotBinding… (conflicts with the A.6.5 binding discipline) or SlotValue… (ambiguous slot-bearing description or context).
• Anchor names: if a §4.2 anchor is materialized as a formal field name, keep …_ref only for fields whose values are concrete RefKind handles, and keep …_id only for identifiers. Avoid introducing generic placeholders such as SpecRef, PolicyRef, or GateRef inside this pattern; use existing concrete ref kinds. When no concrete ref kind exists, the planned-baseline claim is blocked until a governing FPF pattern defines the kind.
• Row vocabulary: treat SlotFillingRow and PlannedFiller as internal names of this pattern. Do not treat them as shared tokens outside this pattern unless a governing FPF pattern defines them.

#Problem frame

FPF frequently needs to make reproducible, reviewable choices about what fills which conceptual slot (specification references, policy references, mechanism-instance references, time selectors, evidence hooks, etc.) before any Work is enacted. These choices must be visible as a planned baseline for a concrete P2W slice (CG-frame, path slice, or publication scope), and must remain distinct from run-time “actuals” and gate decisions.

However, absent a universal WorkPlanning plan item for architecture-by-planned-slot-filling, practitioners tend to hide these choices inside mechanism prose, CG-Spec and CN-Spec descriptions, local cards, or informal checklists—making Part G patterns difficult to universalize and making Work audit trails ambiguous.

SlotFillingsPlanItem addresses this by defining a WorkPlan PlanItem kind whose job is to state, in one place and with explicit context, a mapping:

(Target slot-bearing description, slot kind) → planned filler (ByValue | ByRef(), with edition pins when needed)

and to do so in a form that can be cited by Work enactment and by suite or kit spec pins, without collapsing into “execution” or “decision logging”.

#Problem (what breaks without it)

Without an explicit SlotFillingsPlanItem baseline, at least six failure modes recur:

1. Hidden slot-bearing-description reference and meaning drift: a planned filler is stated without making explicit whose slot set is being filled, allowing silent reinterpretation of SlotKinds across kits or suites.

2. Planning and enactment collapse: plan documents get “backfilled” with run-time values, so there is no stable planned baseline and no clean variance trail. WorkPlan explicitly warns against this.

3. Implicit time (“latest”) and implicit recency: planned claims about comparability or launch readiness omit an explicit Γ_time, which violates the time discipline (“no implicit recency”).

4. Edition ambiguity: references to method, policy, and specification references are not edition-pinned where reproducibility requires it, or the plan mutates the edition vector instead of citing pinned editions (edition changes are crossings, not “plan edits”). A particularly harmful subtype is edition-key backfill: retroactively editing a previously used baseline so that an edition-key change looks like an innocent PlanItem edit (hiding the required GateCrossing witness and breaking audit traceability).

5. Crossing invisibility: cross-context or cross-plane expectations (Bridge + policy ids) are not stated at plan time, so downstream gate crossings appear as “magic” rather than traceable expected constraints.

6. G-pattern fragmentation: each Part G pattern invents its own place to stash planned refs (method pick, comparator pick, QD archive config, etc.), blocking a clean “G.Core” universal layer and making modular reuse brittle.