#Part A – Kernel Architecture Cluster

Preface node heading:part-a-kernel-architecture-cluster:765

#Content

#Onboarding Glossary (NQD & E/E‑LOG)

One‑screen purpose (manager‑first). This pattern gives newcomers a plain‑language starter kit for FPF’s generative engine so they can run a lawful problem‑solving / search loop on day one. It explains the few terms you must publish when you generate, select, and ship portfolios (not single “winners”), and points to the formal anchors you’ll use later. (OEE is a Pillar; NQD/E/E‑LOG are the engine parts.)

Builds on. E.2 (P‑10 Open‑Ended Evolution; P‑2 Didactic Primacy), A.5, C.17–C.19 - Coordinates with. E.7, E.8, E.10; F.17 (UTS); G.5, G.9–G.12 - Constrains. Any pattern/UTS row that describes a generator, selector, or portfolio.

Keywords & queries. novelty, quality‑diversity (NQD), explore/exploit (E/E‑LOG), portfolio (set), illumination map (report‑only telemetry), parity run, comparability, ReferencePlane, CL^plane, ParetoOnly default

#1) Problem frame

Engineer‑managers meeting FPF for the first time need a plain, on‑ramp vocabulary for the framework’s generative engine so they can run an informed problem‑solving/search loop on day one—before formal specifications. Without that, Part G and Part F read as assurance/alignment only, and teams default to single “best” options. This undercuts P‑10 Open‑Ended Evolution and weakens adoption.

#2) Problem

In current practice:

• Single‑winner bias. Teams look for “the best” option and publish a leaderboard, suppressing coverage & diversity signals essential to search.
• Metric confusion. “Novelty” and “quality” are used informally; units/scales are omitted; ordinal values are averaged, breaking comparability.
• Hidden policies. Explore/exploit budgets and governor rules are implicit; results are irreproducible and refresh‑unsafe (no edition/policy pins).
• Tool lock‑in. Implementation terms (pipelines, file formats) leak into the Core, violating Guard‑Rails.

FPF needs a short, normative glossary that names the generative primitives in Plain register and ties each to its formal anchor—so portfolios, not single scores, become the default publication.

#3) Forces

#4) Solution — Normative onboarding glossary and publication hooks

#4.1 Plain one‑liners (normative on‑ramp; formal anchors in C.17–C.19)

(Registers & forbidden forms per LEX‑BUNDLE; avoid “axis/dimension/validity/process” for measurement and scope.)

#4.2 Publication & telemetry duties (where these terms show up)

1. UTS surface (Part F). When a UTS row describes a generator, selector, or portfolio, it MUST surface N, U, C, Diversity_P, E/E‑LOG policy‑id, ReferencePlane, with units/scale/polarity typed under MM‑CHR / CG‑Spec, and lawful references to DescriptorMapRef/DistanceDefRef. (Row schema: F.17; shipping via G.10.)
2. Parity & edition pins (Part G). When QD/OEE is in scope, pin DescriptorMapRef.edition and DistanceDefRef.edition (and, where applicable, CharacteristicSpaceRef.edition, TransferRulesRef.edition) and record policy‑id + PathSliceId. Treat illumination/coverage as report‑only telemetry; publish an Illumination Map where G‑kit mandates parity artefacts. Declare S (Scale Variables) and run at least one scale‑probe (two points along S) when claiming scale‑amenability. Dominance policy defaults to ParetoOnly; including illumination in dominance MUST cite a CAL policy‑id.
3. Tell‑Show‑Show (E.7/E.8). Any arhitectural pattern that claims generative behaviour MUST embed both a U.System and a U.Episteme illustration using this glossary (manager‑first didactics).

#4.3 Minimal recipe (run this on day one)

1. Declare CG‑Frame (what “quality” means; lawful units/scales) and ReferencePlane.
2. Pick 2–4 Q components + a simple DescriptorMap (≥2 dims) for N/D; publish editions.
3. Choose an E/E‑LOG policy (explore↔exploit budget); record policy‑id.
4. Call the selector under G.5 with parity pins; return a set (Pareto/Archive), not a single score.
5. Publish to UTS + PathIds/PathSliceId; Illumination Map is report‑only telemetry by default.

#5) Archetypal Grounding

Informative; manager‑first (E.7/E.8 Tell‑Show‑Show).

Show‑A - SRE capacity plan (selector returns a set). Frame. We must raise service commitment headroom for Q4 without breaking latency SLOs. Portfolio. {cache‑expansion, read‑replicas, query‑shaping, circuit‑breaker tuning, schema‑denorm}. Glossary in action. U = latency@p95 & error‑rate, C = budget ≤ $X, risk ≤ R, N = dissimilarity to current playbook, Diversity_P = adds a previously empty niche in our archive (e.g., “shifts load to edge”). E/E‑LOG starts Explore‑heavy, flips Exploit‑heavy once ≥ K distinct niches are lit. (Publish UTS row + parity pins; illumination stays report‑only telemetry.)

Show‑B - Policy search with QD archive (MAP‑Elites‑class). Frame. Robotics team explores gaits that trade stability vs energy use. Glossary in action. CharacteristicSpace = {step‑frequency, lateral‑stability}, ArchiveConfig = CVT grid, N from descriptor distance, U = task reward, Diversity_P = coverage gain; PortfolioMode=Archive. Families include MAP‑Elites (2015), CMA‑ME/MAE (2020–), Differentiable QD/MEGA (2022–), QDax (2024); publish editions and policy‑ids; treat illumination as report‑only telemetry.

(Optional) Show‑C - OEE parity (POET/Enhanced‑POET). Co‑evolve {environment, method} portfolios; publish coverage/regret as telemetry metrics; pin TransferRulesRef.edition; return sets, not a single winner.

Show‑Epi - Evidence synthesis (U.Episteme). Frame. A living review compares rival causal identification methods (e.g., IV vs. DiD vs. RCT‑adjacent surrogates) across policy domains. Glossary in action. U = external‑validity gain @ F/G‑declared lanes, C = ethics & data‑licence constraints, N = dissimilarity in **ClaimGraph** transformations, D_P = coverage of identification niches in the archive. ReferencePlane = episteme. Illumination/coverage stays report‑only telemetry; selection returns a portfolio of methods per niche. (Publish UTS rows; cite Bridges + CL for cross‑domain reuse; edition‑pin Descriptor/Distance defs where QD applies.)

#6) Bias‑Annotation

Scope. Trans‑disciplinary; glossary applies to both System and Episteme work. Known risks & mitigations. Over‑aggregation: forbid mixed‑scale sums; use CG‑frame and MM‑CHR. Terminology drift: enforce LEX‑BUNDLE registers; ban tool jargon in Core. Optimization monoculture: require portfolio publication where G‑kit mandates parity; illumination stays report‑only telemetry unless a CAL policy promotes it (policy‑id cited).

#7) Conformance Checklist (SCR/RSCR stubs)

#8) Consequences

Benefits. • Immediate usability for engineer‑managers (plain one‑liners) with formal anchors for auditors. • Portfolio‑first culture (sets & illumination) instead of brittle leaderboards. • Edition‑aware comparability; parity/refresh is routine, not ad‑hoc.

Trade‑offs & mitigations. • Slightly longer UTS rows → mitigated by consistent schema and copy‑paste snippets. • Requires discipline on units/scales → mitigated by CG‑frame templates.

#9) Rationale

This pattern instantiates P‑10 Open‑Ended Evolution by making generation‑selection‑publication operational at the on‑ramp: readers get just enough shared vocabulary to run search as standard practice. It aligns with Didactic Primacy (P‑2) and LEX‑BUNDLE (E.10) by keeping definitions plain‑first and scale‑lawful, and with Patterns Layering (P‑5) by pointing to C.17–C.19 for formal anchors without tool lock‑in. The post‑2015 line (MAP‑Elites → CMA‑ME/MAE → Differentiable QD/MEGA → QDax; POET/Enhanced‑POET/Darwinian Goedel Machine) normalised quality‑diversity and open‑endedness as first‑class search objectives; this glossary surfaces those ideas as publication standards, not tool recipes.

#10) Relations

Builds on. E.2 Pillars (P-10, P-2, P-6), A.5 (Open-Ended Kernel), B.5/B.5.2.1 (Abductive loops + NQD integration), C.17–C.19 (Creativity-CHR, NQD-CAL, E/E-LOG).

Coordinates with. E.7/E.8 (Archetypal Grounding; Authoring template), E.10 (LEX‑BUNDLE), F.17 (UTS), G.5/G.9–G.12 (set‑returning selectors, iso‑scale parity, shipping & refresh). Constrains. Any generator/selector/portfolio publication on the Core surface: N‑U‑C‑Diversity_P + policy‑ids; S/Scale‑probe where applicable; parity pins; lawful scales; portfolio‑first where mandated. (Ties into UTS rows and parity artefacts.) Editor’s cross‑reference. For agentic orchestration of scalable tool‑calls under BLP/SLL, see C.24 (Agent‑Tools‑CAL).

#Editor’s note (implementation hint)

This pattern is an on‑ramp: it does not replace C.17–C.19. It binds Plain definitions to publication/telemetry expectations so newcomers can use NQD/E/E‑LOG immediately while experts follow the formal trails.

#A.0:End

#Holonic Foundation: Entity → Holon

Type: Architectural (A)
Status: Stable
Normativity: Normative

“Name the thing without smuggling in its parts.”

#Problem Frame

The first epistemic act in any discipline is to point: “that thing, not the background.” Physics calls the pointed object a system, biology an organism, information science an artifact, philosophy an entity. Reusing any one of these across domains drags hidden assumptions and yields nonsense like “What is the mass of a system of equations?” or “Where is the network interface of a moral theory?” FPF therefore starts from a minimal, domain‑agnostic root that makes such category errors impossible by construction and gives engineers and managers a clean, uniform handle for composition, boundaries and interfaces.

#Problem

If FPF treats system as the universal root, two recurrent failure modes appear:

1. Category Error — physical affordances get projected onto abstract artifacts (ports on theories; kilogram‑mass of paradigms).
2. Mereological Over‑reach — part–whole calculus is applied to genuinely atomic entities (prime numbers, elementary charges), producing meaningless “sub‑parts.”

A robust kernel separates identity from structure: first say what can be singled out, then say what has parts.

#Forces

#Solution — A three‑tier root (Entity ⊃ Holon ⊃ {System, Episteme})

FPF adopts a three‑tier root ontology refining Koestler’s “holon,” with crisp boundaries and safe composition.

#U.Entity — Primitive of Distinction

Anything that can be individuated and referenced. No structural assumptions. Use when you need to name “a something” without committing to having parts.

Naming note (mint vs reuse). U.Entity and U.Holon are minted kernel terms: they reuse familiar words but intentionally diverge from domain‑specific ontologies and DDD “Entity”, so we can reason cross‑domain without importing hidden assumptions.

#U.Holon — Unit of Composition

A U.Entity that is simultaneously (a) a whole composed of parts and (b) a part within a larger whole. Formally, U.Holon ⊑ U.Entity. Well‑formedness constraints:

• WF‑A1‑1 (Single boundary). A holon has exactly one U.Boundary that separates it from its environment.
• WF‑A1‑2 (Γ domain). The universal aggregation operator Γ is defined only on sets of U.Holon (never on bare U.Entity).
• WF‑A1‑3 (Γ scope). A Γ‑application is scoped to a declared context and a single declared temporal scope (design or run); order/time are routed to Γ_ctx / Γ_time (B.1.4).

These constraints make composition rules uniform across domains and prevent Γ from being misapplied.

#Interface primitives: U.Boundary & U.Interaction

Every holon is defined by how it is separated and what crosses the separation.

• U.Boundary — physical or conceptual surface delimiting the holon’s scope.
• U.Interaction — any flow of matter, energy, or information that crosses a boundary. Canonical boundary kinds (with twin archetypes):

This pair (Boundary, Interaction) makes interfaces explicit, reviewable, and testable across domains.

#Inside/Outside decision procedure

To decide whether an entity E is inside a holon H, apply:

1. Dependency test: removing E breaks a core invariant of H.
2. Interaction test: E participates in causal loops wholly within H’s boundary.
3. Emergence test: E contributes to a novel collective property warranting H as a single unit. Fail all three → E is outside. This practical triage prevents “scope creep” and forces explicit modeling of environment vs interior.

Collections vs collectives. A set/collection of holons is not itself an acting unit. If a grouping is expected to act, model it as a U.System holon with its own boundary and attach roles/methods/work to that system (see CC‑A1.6; details in A.2 and A.15).

#Archetypal sub‑holons

FPF fixes two archetypal specializations to ground cross‑domain universality:

Agency rule. Behavioural roles and executed methods/work attach to U.System holons only; U.Episteme is passive content. Any change to an episteme is performed by an external system acting across a boundary (cf. CC‑A1.5 and A.2/A.15).

Naming guideline: keep “System” and “Episteme” for practitioner comfort; reserve Holon for meta‑level discourse and formal signatures.

#Archetypal Grounding (System / Episteme)

Showing the same structural slots filled by a machine and a theory demonstrates the substrate‑independent universality of U.Holon. This is the didactic “Tell–Show–Show” anchor required by the Style‑Guide for architectural patterns.

#Bias-Annotation — Boundary-first modelling risks

This kernel distinction is intentionally boundary‑first: it treats “where the boundary is” as a modelling decision that shapes everything downstream. That framing is powerful, but it can also smuggle bias if boundary choices are made implicitly or for political convenience.

#Conformance Checklist (normative)

Audit tip. CC‑A1.5 is frequently violated when authors write “holon bearing TransformerRole”. Rewrite to “system bearing TransformerRole” or provide the explicit U.RoleAssignment. See A.2/A.15 for role mechanics.

#Common Anti‑Patterns and How to Avoid Them — Manager’s quick checks

1. “Ports on a theory.” Treating a proof corpus as if it had physical connectors. Fix: model U.Interaction only across boundaries; for epistemes, interactions are symbolic flows via carriers and citations (see A.10), not power or mass.
2. “Document edited itself.” Assigning actions to an episteme. Fix: actions are executed by a system bearing a role (A.12/A.15); epistemes are transformed via external transformers acting on their symbol carriers.
3. “Parts everywhere.” Forcing a part–whole onto atomic entities (e.g., prime numbers). Fix: if no meaningful parts exist, stay at U.Entity; apply Γ only to U.Holon.
4. “Scope ≡ section.” Using “scope” as a text region rather than a modeled boundary. Fix: define a U.Boundary and state what crosses it (U.Interaction).

When in doubt: first decide what is a holon, then state its boundary, then list what crosses. Roles and methods come after (see A.2 and A.15).

#Consequences (informative)

#Rationale — Cross‑domain corroboration (post‑2015, informative)

The separation Entity → Holon → {System, Episteme} is not only ontologically clean; it is empirically validated across domains since 2015:

• Compositional open systems. Category‑theoretic treatments show that boundaried components compose safely (decorated cospans, open systems). This mirrors Γ’s reliance on declared boundaries. (Fong & Spivak, 2019; Baez & Courser, 2017)
• Microservices & bounded contexts. Modern software architecture stresses strong service boundaries and local reasoning as the route to evolvability—our U.Boundary and Inside/Outside test encode the same discipline. (Newman, 2021; Vernon, 2022)
• FAIR & provenance. Data/knowledge communities require explicit distinction between content and carrier, and auditable provenance—precisely the System/Episteme + SCR split used in A.1/A.10. (Wilkinson et al., 2016; Boeckhout et al., 2018)
• Digital Twin / Thread. Engineering practice since late‑2010s emphasises the run↔design seam and boundary‑consistent aggregation of subsystems—formalised in our Γ‑family and boundary inheritance rules. (Grieves & Vickers, 2017; NIST DT/Thread reports 2019‑2021)
• Layered control of CPS. Standard‑based, multi‑rate architectures justify explicit holon boundaries and scale transitions—feeding directly into B.2 Meta‑Holon Transition. (Matni et al., 2024)

These streams converge on one point: make boundaries and composition first‑class and separate what a thing is from what it is doing here‑and‑now—the heart of A.1/A.2.

#SoTA-Echoing (post‑2015, informative)

This solution echoes several modern (post‑2015) research and engineering streams. We adopt their boundary‑and‑composition insights, but reject any requirement to commit to a single formalism (per Notational Independence).

#Relations

• Builds / Grounds:

  • A.2 Role Taxonomy — A.1 provides the substantial characteristic (Holon), A.2 introduces the functional characteristic (Role and U.RoleAssignment). Together they prevent role/type explosion and keep agency contextual.
  • A.7 Strict Distinction (Clarity Lattice) — A.1 supplies the slots (Entity/Holon/System/Episteme); A.7 guards their separation in prose and models, stopping Object ≠ Description ≠ Carrier conflations.
  • A.14 Advanced Mereology: Portions & Phases — A.1’s holon substrate is the target of A.14’s edge discipline (ComponentOf, ConstituentOf, PortionOf, PhaseOf); only mereological subtypes build holarchies.

• Interacts with the Γ‑family (B‑cluster):

  • B.1 Universal Algebra of Aggregation — Γ is defined on holons and respects CC‑A1.*; Γ_ctx/Γ_time carry order and temporal composition, Γ_work handles resource ledgers.
  • B.2 Meta‑Holon Transition (MHT) — uses A.1’s boundary and Inside/Outside rules to decide when aggregation yields a new whole with novel properties.
  • B.3 Trust & Assurance Calculus — evidence attaches to carriers (SCR/RSCR) of epistemes; assurance levels depend on A.1/A.10 alignment.
  • B.4 Canonical Evolution Loop — operationalises the design↔run seam at holon boundaries; observation itself is an external transformation across a boundary.

• Specialised by patterns: U.System (Sys‑CAL) and U.Episteme (KD‑CAL) are archetypal sub‑holons that supply domain‑specific invariants while inheriting A.1’s boundary and aggregation duties.

Without the holon, parts drift; without the role, purpose evaporates. (Carry this epigraph with A.1 to cue the A.2 hand‑off.)

#A.1:End

#U.BoundedContext: The Semantic Frame

Type: Architectural (A)
Status: Stable
Normativity: Normative

Make meaning local; make translation explicit.

#Problem Frame

Large systems of thought (and large engineered systems) break down when meaning is treated as globally uniform. The same label (e.g., “role”, “service”, “ticket”, “evidence”) routinely carries incompatible senses across teams, disciplines, standards editions, and historical eras.

FPF needs a first-class mechanism that answers a simple question with precision: “In which semantic frame does this term, rule, or role-claim hold?”

The U.BoundedContext is that mechanism. It makes “it depends” explicit and governable by naming what it depends on.

#Problem

Absent an explicit, first-class semantic frame:

1. Ambiguity becomes structural debt. Integrations silently overwrite meanings (“process” becomes “procedure”; “role” becomes “permission”), and the resulting model cannot be audited.
2. Pluralism looks like contradiction. Two valid perspectives appear mutually exclusive because the frame of reference is implicit (e.g., Pluto as PlanetRole vs DwarfPlanetRole).
3. Roles lose semantic footing. A U.Role without a declared frame degenerates into a global label, violating the kernel’s insistence that roles are contextual masks (A.2, A.2.1).
4. Local rules leak globally. Team- or theory-specific invariants are mistaken for universal laws, producing incoherent cross-domain reasoning.

#Forces

#Prophylactic clarification — Domain family vs U.BoundedContext

To prevent a common category error, Domain (as used colloquially) and U.BoundedContext are not synonyms in FPF, and “Domain” is not a kernel type. Per E.10.D1 (D.CTX), Domain is an informative family label grouping multiple contexts; there is no “domain context”.

Well-formedness constraint (didactic): In any U.RoleAssignment, context is total and points to exactly one U.BoundedContext (cardinality 1..1). Think “specific room” (e.g., Hospital.OR_2025), not “the whole building” (e.g., “Healthcare”).

Manager’s one-liner: A Domain family is the territory label; a Bounded Context is a purpose-made map of one perspective on that territory.

#Solution

FPF elevates semantic framing to a kernel primitive by introducing U.BoundedContext as a first-class holon of meaning. Inspired by Domain-Driven Design (DDD) but generalized beyond software, a bounded context is not a mere namespace: it is a governable model locale with explicit vocabulary, rules, and role taxonomy.

#Term & Definition

• Term: U.BoundedContext
• Definition: A U.BoundedContext is a U.Holon that serves as an explicit semantic frame of reference. It declares a boundary within which a specific vocabulary, role taxonomy, and invariant set are coherent and authoritative. It is FPF’s kernel mechanism for localizing meaning and managing complexity by partitioning a larger conceptual space into smaller, coherent, independently governable semantic locales (Contexts).

Mint vs reuse (informative): The label "Bounded Context" is reused from DDD; U.BoundedContext is the FPF-defined kernel type (generalized beyond software). Cross-context sameness is never inferred from spelling; cross-context alignment is represented only via explicit Bridge artifacts (F.9; E.10.U9; see CC-A1.1.5).

#Core components (normative shape)

A U.BoundedContext is a composite holon whose parts constitute the context’s local “constitution”:

• Glossary (Local Lexicon): A set of U.Lexeme entries (Lang-CHR) defining the local vocabulary and its intended senses. This is where a context can state: “Inside here, ticket denotes U.WorkItem, not U.TravelPermit.”
• Invariants (Local Rules): A set of U.ConstraintRules (Norm-CAL) that must hold for artifacts and processes operating in this context. These rules define the context’s local “physics”.
  • Example (role compatibility): “Within this context, a holder cannot simultaneously play AuditorRole and DeveloperRole.”
  • Example (state transition): “A U.WorkItem can transition from InProgress to InReview, never directly to Done.”
• Roles (Local Taxonomy): A partial order of U.Roles that are defined and valid only within this context. It specifies the “masks” available on this stage (A.2).
• Bridges (Optional alignments): A set of explicit cross-context relations (U.Alignment, formalized in F.9 / E.10.U9) describing how meaning translates when information crosses context boundaries, including loss/fit notes.
  • Example (alignment): “AgileDevelopment:UserStory is congruent (CL=1) to FormalEngineering:Requirement under the stated loss policy.”

#Context interactions with other kernel objects (normative)

• As a U.Holon: A U.BoundedContext has a defined U.Boundary and internal parts (Glossary, Invariants, …). However, contexts do not form holarchies with each other: per E.10.D1 (D.CTX), contexts have no is‑a or containment relations; cross-context relationships are expressed only via explicit Bridges.
• As the semantic frame for U.RoleAssignment: The context field of U.RoleAssignment identifies the unique semantic frame in which the holder-role assignment is interpreted (A.2.1).
• As the scope carrier for rules and objectives: U.Objectives and U.ConstraintRules are typically authored and evaluated relative to a specific context’s invariants.
• As a change target: Context evolution (new invariants, revised glosses, deprecated roles) is modeled as a U.Transformer acting on the U.BoundedContext holon itself. Where time is merely stance (design/run), treat it as a TimeScope tag, not a new context (C‑7; D.CTX).

If meaning is local by design, then translation must be explicit by design.

Admissibility constraints (concept-level; non-deontic).

• BC‑1 (Holon nature). A U.BoundedContext is a U.Holon and declares a U.Boundary.
• BC‑2 (Flat context map). No U.BoundedContext is modeled as inheriting from, containing, or being contained by another U.BoundedContext; cross-context relations are represented only via explicit Bridges (E.10.D1 / E.10.U9).
• BC‑3 (Role localization). Every U.Role is defined in the Roles taxonomy of at least one U.BoundedContext; a "global role" is not a valid kernel object.
• BC‑4 (Invariant scope). Any invariant authored in a Context applies only to holons and processes operating within that Context; cross-context reuse is mediated by Bridges and re‑stated locally.
• BC‑5 (Bridge explicitness). Any interaction or semantic alignment between two Contexts is represented by an explicit Bridge artifact.
• BC-6 (RoleAssignment context field). A U.RoleAssignment references exactly one U.BoundedContext in its context field (cardinality 1..1).
• BC‑7 (Domain is metadata). "Domain" denotes only an informative family label grouping multiple contexts; it is not a kernel type and does not substitute for U.BoundedContext (E.10.D1).

#Archetypal Grounding

The concept of a U.BoundedContext is universal and applies to both physical/operational domains and purely abstract/epistemic ones. Understanding these two archetypes clarifies its role as a fundamental FPF primitive.

Key takeaway from grounding: This illustrates that a U.BoundedContext is not an abstract container but a holon with tangible content. For the engineering team, it's their project's "operating system." For the scientific theory, it's the "intellectual constitution." In both cases, the context defines what is true, what is possible, and what words mean locally.

#Bias-Annotation

This pattern is intentionally universal, but it can be misread through narrower lenses:

• Software-centrism bias: Readers may assume “bounded context” only applies to microservices/teams. Mitigation: the Episteme archetype is first-class; contexts apply equally to theories, standards, and scientific practices.
• Boundary reification bias: Authors may treat boundaries as “natural facts” rather than modelling choices. Mitigation: boundaries are declared for governance and clarity, and cross-context relations are handled via Bridges with explicit loss/fit.
• English-label bias: Examples often use English surface terms, which can hide multilingual drift. Mitigation: language/edition discipline in D.CTX governs when to split/merge contexts; multilingual labels are metadata when semantics are truly bound.

#Conformance Checklist

To ensure U.BoundedContext is used consistently and rigorously, the following normative checks apply.

#Common Anti-Patterns and How to Avoid Them

These failure modes recur when applying U.BoundedContext in real programs and knowledge work.

#Consequences

#Rationale

Lineage and fit with Domain‑Driven Design (DDD).
FPF generalizes the proven DDD idea of a Bounded Context from software into a universal modeling primitive:

Why this matters here.
U.BoundedContext gives U.RoleAssignment (A.2.1) its footing: role meanings are local by design, conflicts are checked inside the same context, and differences across contexts are handled by explicit Bridges instead of “global truth.”

The introduction of U.BoundedContext as a first-class holon is a direct implementation of several core FPF principles and is strongly supported by contemporary practice.

• Philosophical Grounding: The idea that meaning is always local and context-dependent is a cornerstone of late 20th-century philosophy of language (e.g., Wittgenstein's "language-games"). FPF operationalizes this insight.
• Domain-Driven Design (DDD): The concept is a direct borrowing and generalization from Eric Evans' seminal work on DDD, where the Bounded Context is the central strategic pattern for managing complexity in large-scale software. Its success over the past two decades in the software industry provides powerful empirical validation for its utility. FPF elevates it from a software design pattern to a universal ontological primitive.
• Architectural Necessity: For FPF to fulfill its promise of being an "operating system for thought," it needs a mechanism analogous to an OS's "process separation." A U.BoundedContext is precisely that: a protected "memory space" for a model, preventing different models from corrupting each other.
• Enabler for Key Patterns: The Contextual Role Assignment pattern (A.2.1) would be incoherent without a formal definition of "Context." This pattern provides that necessary foundation, making the entire role-based architecture sound.

In essence, U.BoundedContext is the architectural pattern that allows FPF to be both universal in its core principles and specific and pluralistic in its applications. It is the mechanism that tames complexity and makes large-scale, multi-paradigm modeling possible.

#SoTA-Echoing (post-2015 practice alignment)

The U.BoundedContext concept aligns strongly with contemporary (post‑2015) practice in software architecture, socio-technical design, and knowledge/provenance disciplines. Where FPF differs, it does so to preserve kernel universality, explicit loss-aware translation, and auditability.

#Relations

• Constitutes: The foundational "semantic space" for patterns like A.2 Role Taxonomy and A.13 The Agential Role.
• Builds on: A.1 Holonic Foundation, as a U.BoundedContext is itself a U.Holon.
• Constrained by: E.10.D1 D.CTX, which fixes the lexical discipline for “Context”, forbids context hierarchies, and makes Domain family informative.
• Interacts with:
  • Norm-CAL: A context's Invariants are typically expressed as U.ConstraintRules.
  • Lang-CHR: A context's Glossary is a collection of U.Lexemes.
  • Decsn-CAL: Decisions and objectives are often scoped to a specific context.
  • F.9 Alignment & Bridge: the canonical locus of cross-context relations and loss policies.
• Enables: The resolution of conflicts as modeled in D.3 Holonic Conflict Topology, by showing that many conflicts are context-dependent.

#A.1.1:End

#Role Taxonomy

Type: Architectural (A) Status: Stable Normativity: Normative

A holon’s essence tells us what it is; its roles tell us what it is being, here and now.

#Problem frame

Pattern A.1 established the substantial characteristic of the core (Entity → Holon → {System, Episteme, …}), cleanly separating identity from structure and aggregation. The present pattern introduces the functional characteristic: how a holon participates in purposes within a bounded context and for some interval. This extends the early sketch of A.2 and tightens its alignment with A.7 (Strict Distinction): roles are not parts and not behaviours; they are contextual masks that a holon wears while behaviours are handled by Method/Work.

#Problem

Without an explicit role calculus:

1. Type explosion & conflation. Each new purpose breeds a new “subtype” (PumpAsCoolingLoop, PumpAsFuelLoop, …), violating parsimony and fusing substance with function.
2. Agency opacity. It becomes unclear whether any system may act as a transformer/agent, or only pre-declared special kinds.
3. Epistemic blindness. Knowledge artefacts (papers, proofs) cannot be given roles, blocking modelling of citation, evidence, or design-time justification.

#Forces

#Solution

We elevate Role to a first‑class semantic construct: a context‑bound mask (capability/obligation schema) worn by a holon. Behaviour and resource deltas live in Method/Work, not in the role itself.

#S‑level definitions (normative)

• U.Role — a context-bound capability/obligation schema that a holon may bear (play) for a time interval. A role has no structural parts (it does not participate in A.14 partOf) and no resource deltas of its own. Role refinement/bundling is expressed via in‑Context relations (≤, ⊥, ⊗) rather than mereology. (A7 guard)
• U.RoleAssignment — a first-class assignment record recording that a holon bears (plays) a role in a bounded context over an optional Window. Keep the signature aligned with A.2.1 Role Assignment Standard; governance metadata (authority/justification/provenance) is captured via U.RoleAssigning and the evidence graph (A.10).

U.RoleAssignment {
  holder        : U.Holon,
  role          : U.Role,
  context       : U.BoundedContext,
  window? : U.Window
  justification?: U.Episteme,  // why (standard, SOP, evidence)
  provenance?   : U.Method     // how assignment/verification was done (NOT the role's bound method set)
}

Short form (readable): Holder#Role:Context@Window.

Why a first-class assignment record? It keeps identity (holon), function (role), context (semantics), and time (run-window) separate yet linked, preventing the substance/function conflation identified above. The early playsRoleOf(Holon, Role, span) relation in the draft is subsumed by U.RoleAssignment and extended with Context (and optional governance fields).

#Temporal & behavioural alignment

• Method (intension) vs Work (occurrence). A U.Method is a design‑time, order‑sensitive capability: what can be enacted, under which preconditions/invariants, with what admissibility/acceptance gates. A U.Work is the dated, spatiotemporally bounded enactment of such behaviour by a system bearing a role (A.15.1).
• MethodDescription is representation (viewpoint), not “the method itself”. U.MethodDescription is an U.Episteme that represents a method under an explicit viewpoint. Step‑graphs/scripts/workflows are one common viewpoint, but not universal. Other valid viewpoints include state‑machines, dynamical/solver/controller models, lab protocols, and quantum circuits/channels. A method itself need not admit a step decomposition; only a given description might.
• Executable chain (who / what / how / when). A behavioural Role is eligible/authorized for one or more Methods (design‑time, Context‑local). A Work is isExecutionOf a specific MethodDescription version (run‑time) and cites performedBy = U.RoleAssignment. Together, these anchors answer “what happened, by which method, under which role” without collapsing design‑time into run‑time.
• Resource accounting lives in Work. Only U.Work carries resource deltas (feeds Γ_work); Roles/Methods/MethodDescriptions do not.

Lexical note (A.6.P trigger). In the Role–Method–Work cluster, bindsMethod is a technical token meaning “Context‑local eligibility/authorization of a Role for a Method”. Do not use plain “bind/rebind” as umbrella prose for editing relationships; when describing edits, prefer explicit change classes (declare/withdraw/retarget/revise/rescope/retime/refreshWitnesses).

#Admissibility constraints (concept-level; non-deontic).

1. Locality. role ∈ Roles(context). Outside its context, a role’s meaning is undefined.
2. Structural‑mereology firewall. No Role (nor Method/MethodDescription) may appear as a node in any A.14 partOf chain; holarchies are for substantial holons only. Role refinement/bundling (≤, ⊗) and method relations (refinement, factorization, step/phase views) are not partOf and MUST NOT be rewritten into structural parthood.
3. Multiplicity. A holder may bear multiple roles concurrently; a role may be borne by many holders—subject to each context’s compatibility rules.
4. Time anchoring. window (if present) is non-empty and finite for run‑time claims; open‑ended assignments are allowed but must be traceably open‑ended from an assignment time (A.2.1). Design‑time bindings are timeless but descriptions are versioned via U.MethodDescription identity.
5. Behavioural coherence. For any U.Work window, the performer’s cited RoleAssignment and the executed MethodDescription must align in the same Context: work.performedBy = RA, work.isExecutionOf = MD, and RA.role is eligible/authorized for the Method represented by MD. (No hidden role swaps; no implicit method drift.)

#Taxonomic frame (within a context)

Within each U.BoundedContext, role names are organised as a partial order (refinements) plus an incompatibility relation (mutually exclusive roles). Typical substrate‑neutral anchors:

Domains refine these anchors: e.g., CoolingCirculatorRole, CitationSourceRole, LemmaRole.

#Archetypal Grounding (Tell–Show–Show: System / Episteme)

Tell. A single holon can be the same bearer across time while taking on different, context‑bound roles. A role is a mask (capability/obligation schema) that explains what it is being in a given U.BoundedContext; behavioural facts and resource deltas remain in U.Method / U.Work.

Show.

System case — Cooling loop PumpUnit#3#HydraulicPump:Plant‑A@2025‑08‑08..open HydraulicPumpRole ↦bindsMethod↦ CentrifugalPumpingMethod (design‑time, Context‑local eligibility) CentrifugalPumpingMethod ↦isDescribedBy↦ centrifugal_pump_curve.ld@v7 (MethodDescription viewpoint; step‑graph OR dynamics, as appropriate) run‑2025‑08‑08 isExecutionOf centrifugal_pump_curve.ld@v7; performedBy PumpUnit#3#HydraulicPump:Plant‑A@2025‑08‑08..2025‑08‑08 (run‑time Work) (Behavioural/resource facts live in Work; method semantics live in the referenced MethodDescription viewpoint.)

Episteme case — Standard in design RFC‑9110.pdf#ProtocolStandard:WorldWideWeb justifies MethodDescription selection; the system bearing TransformerRole is the design service that executed the selection work. The episteme did not act.

Collective vs set (safety pitfall) A set {Alice, Bob, 3.14} has no behaviour; a team is a system with boundary, coordination Method, and supervision Work; only the latter can bear agentic roles.

#Bias-Annotation

Lenses tested: Arch, Onto/Epist, Prag, Did. Scope: Universal (A‑cluster).

• Architecture bias (Arch): treating roles as structural parts can smuggle function into mereology and break holarchies.
  Mitigation: keep partOf chains role‑free; roles are not constituents (see CC‑A2.1).
• Onto/Epist bias (Onto/Epist): anthropomorphising epistemes collapses evidence into agency.
  Mitigation: epistemes can justify/authorize; only systems perform methods and work (CC‑A2.2).
• Pragmatic bias (Prag): over‑contextualising can fragment reuse and create naming drift.
  Mitigation: require explicit :Context binding and explicit bridges instead of silent equivalence (CC‑A2.4).
• Didactic bias (Did): metaphors (“mask”) may be misread as informal.
  Mitigation: bind obligations to CC items; avoid imperative prose outside CC.

#Authoring guidance (for engineers and leads)

• Name roles for intent, not mechanics. Prefer CoolingCirculatorRole over ChannelFluidWithCentrifugalProfile.
• Pin the context early. If two teams disagree, split contexts and (optionally) define an alignment bridge; do not over‑generalise the role.
• Document the enactment chain. For any operational claim, be ready to point to: RoleAssigning → RoleAssignment → (Role ↦bindsMethod↦ Method) ↔ MethodDescription → Work. (Readers’ dictionary: workflow/script/state‑machine/dynamical model/quantum circuit → MethodDescription; run/job/operation → Work.)

#Conformance Checklist (CC‑A2.*)

Note. CC‑A2.2 aligns with A.7 Role‑domain guards (“behavioural roles’ domain = system; epistemes bear non‑behavioural roles only”).

#Common Anti-Patterns and How to Avoid Them

1. “Transformer as system subtype.” ✗ “U.TransformerSystem builds pumps.” ✓ “RobotArm R‑45#Transformer:Plant‑A executed Work W.” (Role is a mask; behaviour is Method/Work.)

2. “Role as part.” ✗ “The pump’s role is one of its components.” ✓ Roles are never parts; components are substantial. Keep all partOf chains role‑free.

3. “Episteme acts by itself.” ✗ “The PDF enforced the SOP.” ✓ An episteme can hold roles like ProtocolStandard in context, but only a system performs the Method/Work that uses it.

4. “Context leakage.” ✗ “Pluto is Planet and DwarfPlanet.” (in one tacit space) ✓ “Pluto#Planet:Early20thCenturyAstronomy; Pluto#DwarfPlanet:IAU_2006_Definition.” No contradiction—different bounded contexts. (Illustrative of U.RoleAssignment semantics carried forward from the A.2.1.)

5. “Method = workflow (step list) by default.” ✗ “The method is the ordered list of steps 1..n.” ✓ A Method is a design‑time capability; “steps” (or their absence) are a property of a MethodDescription viewpoint. A Work executes a specific MethodDescription; use a workflow/script view when step semantics matter, and use other views (dynamics/solver/circuit/channel) when steps are not meaningful.

#Consequences

#Rationale (post‑2015 cross‑domain corroboration)

Why insist on roles as contextual masks and externalised transformers?

1. Constructor Theory (2015–2022). Post‑2015 work by Deutsch & Marletto re‑centres physics on possible tasks and constructors rather than objects, mirroring FPF’s TransformerRole: behaviour is attached to “who can realise a task,” not to substance per se. Our separation of SubstantialHolon vs Role and the insistence on external transformers directly echo this shift. (Conceptual alignment noted in A.2 Solution and A.12 intent.)
2. Layered Control Architectures (Matni–Ames–Doyle, 2024). The modern control stack cleanly externalises regulators and planners relative to plants. FPF’s obligatory “system bearing TransformerRole” (A.7, A.12) is isomorphic to that separation, keeping supervision and actuation outside the controlled holon.
3. Active‑Inference / Agency spectrum (2017–2023). Contemporary models treat agency as graded and contextual (percept‑act loops tuned by free‑energy bounds). A.13 adopts exactly this: AgentialRole is a role worn by a holon, with graded measurements via Agency‑CHR, not a static type.
4. Basal Cognition & multi‑scale organisation (2019–2024). Fields & Levin argue for cross‑scale control and information flows; FPF encodes this via Γ‑flavours and the Meta‑Holon Transition triggers, ensuring Role assignments compose across scales without collapsing identity into function.
5. Knowledge ecosystems & safety cases (2018–2025). Modern assurance relies on traceable evidence and conservative integration (no “truth averaging”): our A.10 anchors (SCR/RSCR) and Γ_epist’s weakest‑link fold implement that discipline and forbid self‑evidence.

Summing up: post‑2015 science and engineering converge on roles as contextual capabilities, externalised control, and traceable evidence. A.2 codifies these insights in a substrate‑neutral way, keeping the Core small yet powerful.

#SoTA-Echoing (post‑2015 alignment, informative)

Note. Prefer citing a maintained SoTA synthesis pack for roles/contexts if your Context has one.

#Relations

• Builds on: A.1 Holonic Foundation (role/mereology split), A.7 Strict Distinction (role ≠ behaviour; episteme ≠ carrier), A.14 Advanced Mereology (no roles in holarchies).
• Specialises / Coordinates with: A.13 Agential Role & Agency Spectrum (behavioural roles over systems; graded agency), A.15 Role–Method–Work Alignment (bindsMethod / isExecutionOf discipline).
• Constrains / Used by B‑cluster: B.1 Universal Algebra of Aggregation (Γ) (keep order/time in Γ_ctx/Γ_time; keep provenance in Γ_epist), B.2 Meta‑Holon Transition (promotion when supervision/closure appears), B.3 Trust & Assurance (evidence & congruence).
• Interlocks with E‑cluster (governance & language): E.10 Lexical Discipline (registers, tier disambiguation, local aliases like “Transformer”), E.5.1 DevOps Lexical Firewall (ban tooling tokens in Core patterns).
• Reinforces: A.10 Evidence Graph Referring (external transformer; SCR/RSCR), A.12 External Transformer Principle (agent externalisation).

#A.2:End

#U.RoleAssignment: Contextual Role Assignment

Type: Definitional (D) Status: Stable Normativity: Normative

with Role Performance View, U.RoleStateGraph (RSG), and Role Characterisation Space (RCS) hooks

Builds on: A.1 Holonic Foundation, A.1.1 U.BoundedContext, A.2 Role Taxonomy.
Coordinates with: A.13 Agential Role & Agency Spectrum, A.15 Role–Method–Work Alignment, E.10.D1 D.CTX (Context discipline), E.10.D2 Strict Distinction.
Lexical discipline. Context ≡ U.BoundedContext (E.10.D1). Appointment is colloquial only; the canonical term in this specification is Role Assignment (see CC‑LX‑1).

Mint vs reuse. This pattern defines U.RoleAssignment and U.RoleEnactment and introduces the labels Role Characterisation Space (RCS) and Role State Graph (RSG) as intensional facets recorded in RoleDescription / RoleSpec. It reuses existing kernel terms (U.Holon, U.System, U.Episteme, U.BoundedContext, U.Work, U.Method) without changing their meanings.

#Problem frame

Intent. Provide one, universal, context‑local way to say who is being what, where (and when) without altering what the thing is. The same grammar works for people, machines, software, teams, and also for knowledge artefacts (epistemes) when they hold statuses rather than perform actions.

Scope.

• Defines U.RoleAssignment (binding a holder holon to a role inside a bounded context, optionally within a time window).
• Separates that binding from U.RoleEnactment (the run‑time fact that a piece of Work was performed under that assignment).
• Names the Role Characterisation Space (RCS) and the Role State Graph (RSG) as intensional facets of a Role (recorded in its RoleDescription, upgraded to RoleSpec only after tests exist).
• Declares eligibility constraints so Roles apply to the right holon kinds, without badge‑of‑badge chains like “TransformerRole is assigned to be AgentRole”. If your Context wants taxonomic inheritance between role names, express it with in‑Context role algebra (≤), not via chained assignments.
• Declares eligibility constraints so Roles apply to the right holon kinds, without badge‑of‑badge chains like “TransformerRole is assigned to be AgentRole”. If a Context intends taxonomic inheritance between role names, that relation is expressed in‑Context via role algebra (≤), not via chained assignments.

Non‑goals. No storage models, no workflows, no org charts. This is a thinking Standard; all semantics are notation‑free.

#Problem

1. Type explosion. Baking transient function into rigid types (“CoolingPump”, “AuditDeveloper”) violates parsimony and makes change brittle.
2. Context drift. Labels like Operator, Process Owner, Standard slide in meaning across teams/years when not tied to a Context.
3. Actor vagueness. Work logs state that things happened but not who, in what capacity, under which local rules.
4. Category leaks. Documents “do” tasks; deontic statuses are treated like run‑time states; capabilities are confused with permissions.
5. Role chains. Attempting “System ↦ TransformerRole ↦ AgentRole” hides intent and smuggles taxonomy into the data plane.

#Forces

#Solution

#Canonical definition (notation‑free)

U.RoleAssignment is a **context-local assignment:

RoleAssignment ::=
  〈holder: U.Holon,
   role: U.Role,
   context: U.BoundedContext,
   window?: U.Window,
   justification?: U.Episteme,
   provenance?: U.Method〉

Admissibility constraints (concept‑level; non‑deontic).

• Invariant RA‑1 (Locality). role ∈ Roles(context). The role’s meaning is exactly the one recorded in that Context’s RoleDescription/RoleSpec.
• Invariant RA‑2 (No role‑of‑role). holder : U.Holon and holder ∉ {U.Role, U.RoleAssignment}. (Roles/assignments are never holders.)
• Invariant RA‑3 (Eligibility by role kind).
  • Behavioural roles (agential/transformer/observer/speech and their refinements): holder is a U.System. Only systems can enact Methods and produce Work.
  • Status roles (epistemic‑status / normative‑status / service‑governance): holder is a U.Episteme. Epistemes never enact Work; they gate and justify.
  • Context refinements may tighten eligibility (e.g., “Approver must be human”) but are restrictions of the System/Episteme split (they do not weaken it).
• Invariant RA‑4 (Window discipline). If window is present, enactments occur within it. If window is absent, interpret the assignment as open‑ended from an assignment time that is still traceable (e.g., via an issuing U.RoleAssigning SpeechAct Work or other evidence).
• Invariant RA‑5 (Separation). A RoleAssignment confers the capacity/authorization to act (or the status to be recognised), but it is not behaviour (no Work implied), not capability (intrinsic ability lives elsewhere), and not structure (it does not participate in BoM / part‑of structure).

Governance metadata (optional but first‑class when present).

• justification carries why the assignment is valid in this Context (policy, standard, evidence Episteme).
• provenance carries how the assignment was issued or verified (method reference; may link to a U.RoleAssigning work step in the evidence graph).

Didactic read. Think badge (who wears which mask, where, when). The rules for the mask live in the room (Context).

Two assignment modes. A RoleAssignment can be: (a) Authoritative — issued by an authority or policy in the Context (often via a U.RoleAssigning SpeechAct Work); it can open a Green‑Gate for steps that require explicit authorization. (b) Observational — an evidence‑backed classification that the holder occupies a Role in this Context (e.g., “Moon as SatelliteRole:IAU_2006”). Observational assignments never by themselves open operational Green‑Gates; they can gate decisions and analysis.

#Role Enactment (distinct from the assignment)

U.RoleEnactment captures the run‑time fact that a specific piece of Work was performed under a specific Role Assignment:

RoleEnactment ::= 〈work: U.Work, by: U.RoleAssignment〉

Admissibility constraints (concept‑level; non‑deontic).

• Invariant RE‑1 (Actor reality). by.holder : U.System. (Epistemes never enact Work.)
• Invariant RE‑2 (Temporal fit). work.window overlaps by.window (or by.window is open and contains work.window).
• Invariant RE‑3 (Method gate). For the MethodStep realised by work, by.role satisfies the step’s requiredRoles in that same Context (directly or via ≤ specialization inside the Context).
• Invariant RE‑4 (Traceability shape). U.Work records cite the performer as performedBy = some U.RoleAssignment. U.RoleEnactment is the conceptual (or derived) association 〈work, work.performedBy〉; if a system persists it explicitly, it is 1:1 with Work.

Reading: Assignments authorize; enactments happen. That single sentence prevents months of muddled logs.

Role Enactment is the occurrence of U.Work performed by a holder while a valid U.RoleAssignment for the required Role is in an enactable state of its RoleStateGraph (A.2.5) within the same Context. Enactment is generic: it includes operational work (e.g., actuation) and communicative work (speech acts such as approvals).

#Role Characterisation Space (RCS) & Role State Graph (RSG)

These are intensional facets of a Role, not containers “inside” the Role. They are recorded in the RoleDescription (or RoleSpec once harnessed), per E.10.D2.

• RCS (Role Characterisation Space). A set of named characteristics that parameterise how the Role is understood in a Context (e.g., AgencyLevel ∈ {None, Assisted, Delegated, Autonomous}; SafetyCriticality ∈ {SC0…SC3}).

• RSG (Role State Graph). A directed graph of named states (nodes) and admissible transitions (edges) for the Role within the Context (e.g., {Eligible → Authorized → Active → Suspended → Revoked}).

  • Each state has a Conformance Checklist (set of observable cues) supporting Evaluations (“X ∈ Authorized@context in W”).
  • RSG governs role state transitions, independent of any Work instance.

Discipline. Prefer the phrasing “Role is characterised by RCS/RSG recorded in RoleDescription”; avoid “Role contains its states.”

#Shorthand & reading

The canonical compact form used in prose and diagrams is:

Holder#Role:Context@Window

Examples:

• PLC_17#Transformer:PipelineOps@2025‑04‑01..2025‑06‑30
• ISO_26262v2018#NormativeStandard:AutoSafetyCase (status role on an Episteme; no enactment)

The shorthand is didactic; the semantics are those of §§4.1–4.3.

#No role chains (use algebra, not badge‑of‑badge)

Chained assignments are ill‑formed for encoding taxonomy (see Invariant RA‑2 and CC‑ELIG‑3). Chaining hides intent and defeats validation.

Taxonomic inheritance between role names is declared explicitly in the Context’s role algebra. For example, if (per A.13) your Context treats every transformer as a kind of agent, state:

• TransformerRole ≤ AgentialRole (in that Context’s role algebra)

When a MethodStep requires two independent roles, express the conjunction where it belongs:

• the MethodStep requires both roles; the holder wears two badges, not a badge‑of‑a‑badge.

#Eligibility across holon kinds (normative matrix)

A Role’s family constrains who can wear its badge. Eligibility is part of didactic hygiene and prevents chains like “Transformer → Agent”.

#Holder kinds (recap)

• U.System — any acting holon (person, device, software service, team, organization, socio‑technical unit).
• U.Episteme — any knowledge unit (document, dataset, model, standard, Standard).
• U.Holon — supertype; only Systems enact Work; Epistemes can only hold status roles.

#Role‑kind × holder matrix

Invariant — RA‑3 (eligibility) (restated): RoleAssignments are ill‑formed if they violate this matrix. A Context may tighten (e.g., “Approver must be human”), never loosen.

Conformance checks (easy to remember).

• CC‑ELIG‑1. If role.family ∈ {Agential, Transformer, Observer, Speech}, then holder : U.System.
• CC‑ELIG‑2. If role.family ∈ {Epistemic‑Status, Normative‑Status, Service‑Governance}, then holder : U.Episteme.
• CC‑ELIG‑3. No “role of a role”: role is bound to a holder, not to another role or assignment.

#Role algebra within a single Context (meaning relations)

Role algebra

The in‑Context role algebra relates role types inside one U.BoundedContext. It is not mereology. Its operators (≤, ⊥, ⊗) is specified normatively in A.2.7 U.RoleAlgebra.

A.2.1 relies on it for (i) requiredRoles substitution checks (≤), (ii) separation‑of‑duties validation (⊥), and (iii) conjunctive bundles (⊗), but does not restate the operator semantics here.

#Time & state transition calculus (windows, RSG, enactability)

Assignments authorize, enactments happen — in time. RSG governs the role’s state transitions; window governs the binding’s validity.

#Windows and overlap

• Window form: @t_start..t_end (ends may be open).
• RE‑2 (temporal fit) (restated): work.window lies within (or overlaps appropriately with) assignment.window.
• Handover pattern: Close A#Role@..t and open B#Role@t.. — history is preserved by closing windows rather than deletion.
• (Conformance hook.) See CC‑WIN‑1: preserve history by closing windows rather than erasing RoleAssignments.

#RSG gating of enactment

Each Role’s RoleDescription/RoleSpec defines an RSG with named states; some states are enactable.

• Delegation. Normative author‑facing requirements for U.RoleStateGraph structure (including enactability marking and per‑state checklists) and the shape of StateAssertion evidence are defined in A.2.5; A.2.1 only relies on the resulting enactment gate.
• Invariant RE‑5 (RSG gate). A U.RoleEnactment is valid iff at enactment time the U.RoleAssignment can be supported by a valid StateAssertion that the holder is in an enactable state of the Role’s RSG in this Context.
• (A.2.5 hook.) The Role’s U.RoleStateGraph (A.2.5) identifies enactable states and attaches a Conformance Checklist to each state; checklist verdicts can be recorded as StateAssertions (see SCR‑A2.5‑S02/S03).
• Example. SurgeonRole states: Eligible → Authorized → Active → Suspended → Revoked. Only Active is enactable. A pre‑op checklist produces StateAssertion(SurgeonRole, Active).

Practical reading. Badge valid (window) ∧ state is right (RSG) ⇒ you may act.

#Suspensions, revocations, probation

• Suspend: transition to a non‑enactable state (e.g., Suspended). Keep the assignment’s window open; enactment is blocked by RE‑5.
• Revoke: either (a) close the window, or (b) transition to Revoked (non‑enactable).
• Probation: a dedicated RSG state with limited enactability (e.g., only under supervision, modelled as an extra required role on Method steps).
• Discipline (A.2.5). RSG transitions are explicit; no implicit “back to Active”.

#Typical temporal patterns (didactic)

• Shift rotation. A#Role@08:00..16:00, B#Role@16:00..24:00 — clean handover, no ⊥ issues.
• Shadowing. Trainee#Role@.. + Mentor#SupervisorRole@..; Method steps require both roles.
• Emergency bundle. SoloOperator := Incision ⊗ Hemostasis ⊗ Suturing; activate only under declared emergency (Context‑level policy).

#Integration with A.15 (Role–Method–Work alignment)

One line. A U.MethodDescription names the roles it needs; a U.Work cites the concrete U.RoleAssignment that enacted the step; the RSG state + window gates that enactment.

#Design‑time Standard (inside U.MethodDescription)

For every MethodStep:

• requiredRoles — a list of U.Role from the same Context as the step. Example. In Hospital.OR_2025, step “Make incision” has requires: [IncisionOperatorRole].
• Role algebra in‑Context applies: if the Context defines IncisionOperatorRole ≤ SurgeonRole, then requires: [SurgeonRole] also admits holders of IncisionOperatorRole.
• Separation of concerns. Capability checks (does the holder can?) belong to U.Capability and resource limits; authorization belongs to U.RoleAssignment + RSG.

#Run‑time check (inside U.Work)

A U.Work record provides (or allows derivation of) the fields needed to satisfy CC‑ENACT‑1..3:

• performedBy = a concrete U.RoleAssignment (not just a person/system name).
• Window gate. The Work timestamp falls inside the assignment’s @Window.
• State gate. At that timestamp, an enactable state for the assignment is proven by a StateAssertion (the checklist verdict for a named RSG state).
• Role algebra gate. The assignment’s role is either one of requiredRoles or a specialization (≤) thereof; bundles (⊗) expand to conjunctions; incompatibilities (⊥) forbid overlaps on the same holder.

#Evaluation & acceptance (link to services & deontics)

• Observation. The Work produces U.Observation(s).
• Evaluation. A U.Evaluation compares Observations with AcceptanceClause(s) referenced by a promise content clause (U.PromiseContent) or a RequirementRole.
• SoD hook. If the step or evaluation demands independence (e.g., “not performed by its reviewer”), enforce via ⊥ between PerformerRole and ReviewerRole in the same Context.

#Planning & scheduling (design‑time “who will enact”)

• U.WorkPlan (aka “WorkDescription” in prose) binds forthcoming steps to candidate RoleAssignments and time windows.
• Checks before the fact. Validate windows (no gaps/overlaps where disallowed), enforce ⊥, ensure expected RSG state will be enactable at scheduled time (or flag a pre‑flight checklist).

Didactic cue. Think “Step asks for badges; Run cites a badge; Badge must be valid & green.” (Badge = RoleAssignment; valid = window; green = RSG state with a fresh StateAssertion.)

#Cross‑Context bridges in practice (with CL penalties)

Cross‑Context role substitution is Bridge‑only and is specified in F.9 (with CL/waiver regimes) and B.3 (CL‑penalty routing).

A.2.1’s only rule is no substitution by label: any “Role_B@B satisfies Role_A@A” claim used for checking or enactment MUST cite an explicit Bridge (direction, CL, loss notes) and MUST NOT override in‑Context ≤, ⊥, or ⊗.

#Everyday pattern snippets (didactic moves)

Use these micro‑moves to think and speak cleanly; no tooling required.

1. “Who can do this step?” On a MethodStep, write requires: [RoleX]. In your head, expand: “Any performedBy whose role ≤ RoleX, with a valid window and enactable RSG state.” Example: requires: [SurgeonRole] and IncisionOperatorRole ≤ SurgeonRole ⇒ Dr.Kim#IncisionOperatorRole:Hospital.OR_2025 is admissible iff Active.

2. Handover without history loss. Close one window, open another. Never delete. Alex#IncidentCommander:SRE_Prod@08:00..12:00 Riya#IncidentCommander:SRE_Prod@12:00..20:00

3. Independence by construction (SoD). Declare Developer ⊥ IndependentAuditor. Then it’s impossible (by validation) to have overlapping windows on one holder for both roles.

4. Supervision as bundle. Model apprenticeship by requiring Trainee ⊗ Supervisor on sensitive steps, or by RSG state Probation that flips enactable only if SupervisorRole is also present.

5. Same badge name in two Contexts. LeadEngineer:ProjectPhoenix ≠ LeadEngineer:DivisionR&D. If you must relate, create a Bridge with CL & loss notes; never rely on the name.

6. Documents don’t act; they frame. Replace “the SOP executed X” with: SOP_v4#RequirementRole:SafetyCase and a SpeechAct “approve run” by QA_Officer#AuthorizerRole:Plant_2025.

7. Window + state ⇒ permission. Quick mental check: badge valid? (window) ∧ state OK? (RSG) ⇒ go; else no‑go.

8. Communicative enactment (approval) CAB_Chair#ApproverRole:ChangeControl@2026-05-01T10:05 performs a SpeechAct Work “Approve Change-4711”. Effect: moves ApproverRole’s RSG state from Authorized?→Approved and opens the Green‑Gate for the operational step “Deploy Change-4711” (performed by a different RoleAssignment).

#Archetypal Grounding (three disparate arenas)

Goal. Show that the same assignment Holder#Role:Context@Window, plus RCS (Role-Characterisation Space) and RSG (Role-State Graph), works uniformly for operational systems, software/service operations, and knowledge governance.

Natural systems note. Spontaneous physical phenomena (e.g., Moon orbiting Earth) are modeled as U.Dynamics, not as U.Work. An observational RoleAssignment like Moon#SatelliteRole:IAU_2006 is valid classification but does not imply enactment of a method.

#Industrial operations (welding cell)

Role (family). WelderRole (Transformer) *RCS (illustrative characteristics).

• ProcessClass ∈ {MIG, TIG, Spot}
• QualifiedMaterial ∈ {Al, SS, Ti, …}
• MaxCurrentAmp ∈ ℝ⁺
• SafetyProfile ∈ {Standard, HotWork, ConfinedSpace}

RSG (named states). Unqualified → Qualified → Authorized → Active → Suspended → Revoked (enactable: Active only)

Assignments.

• Robot_SN789#WelderRole:AssemblyLine_2025@2025‑02‑01..open
• Robot_SN790#WelderRole:AssemblyLine_2025@2025‑02‑01..open

StateAssertions (via checklists).

• StateAssertion(WelderRole, Qualified, AssemblyLine_2025, @2025‑02‑01..2026‑02‑01) — training & test weld coupons.
• StateAssertion(WelderRole, Active, AssemblyLine_2025, @2025‑03‑01..open) — daily pre‑shift checks + gas/torch inspection.

Enactment (gated by RSG). A U.Work entry W#Seam134 is valid only if performedBy = Robot_SN789#WelderRole:AssemblyLine_2025 and an Active StateAssertion covers the timestamp. If the torch‑health checklist fails, RSG transitions Active → Suspended; further seams are blocked by RE‑5.

#Software & cloud operations (continuous delivery / SRE)

Roles (families).

• DeployerRole (Transformer) — authorises execution of deployment Methods.
• IncidentCommanderRole (Agential/Speech) — directs response and issues SpeechActs (declares incident states).

RCS (illustrative).

• DeployerRole: Env ∈ {staging, prod}, ChangeWindow, RollbackAuthority ∈ {self, peer, CAB}.
• IncidentCommanderRole: OnCallTier ∈ {L1,L2,L3}, ServiceScope, PageDuty ∈ {primary, secondary}.

RSGs (named states).

• DeployerRole: Eligible → Authorized → Active → Suspended (enactable: Active).
• IncidentCommanderRole: OnCall → Engaged → Handover → Rest (enactable: Engaged).

Assignments.

• sCG‑Spec_ci_bot#DeployerRole:CD_Pipeline_v7@2025‑04‑01..open
• Alex#IncidentCommanderRole:SRE_Prod@2025‑04‑10T08:00..2025‑04‑10T20:00

StateAssertions (via checklists).

• DeployerRole/Active: completed change ticket, green pre‑deploy tests, peer‑review check mark.
• IncidentCommanderRole/Engaged: accepted page, situational brief read, comms‑channel opened.

Enactment.

• A deployment Work is valid only with performedBy: sCG‑Spec_ci_bot#DeployerRole:CD_Pipeline_v7 and Active state asserted for the moment of start.
• Declaring Incident SEV‑1 is a SpeechAct Work performed by Alex#IncidentCommanderRole:SRE_Prod in Engaged state; it changes deontic conditions (e.g., elevates RollbackAuthority).

#Knowledge governance (standards & requirements)

Roles (families).

• NormativeStandardRole (Normative‑Status Episteme) — a document that is the standard in this Context.
• RequirementRole (Deontic‑Status Episteme) — a statement that binds behaviour in this Context.

RCS (illustrative).

• NormativeStandardRole: Scope, Edition, ApplicabilityWindow.
• RequirementRole: BindingClass ∈ {shall, should, may}, TargetRole, AcceptanceClauseRef.

RSGs (named states).

• NormativeStandardRole: Proposed → Adopted → Effective → Superseded (enactable: N/A — Episteme roles are non‑enactable; they gate others).
• RequirementRole: Draft → Approved → Effective → Retired (non‑enactable).

Assignments.

• ISO_26262_ed2.pdf#NormativeStandardRole:AutoSafetyCase_2025@2025‑01‑01..open
• REQ‑BRAKE‑001.md#RequirementRole:AutoSafetyCase_2025@2025‑03‑05..open

Effects (gating, not acting).

• A system’s Work (e.g., HIL test run) is evaluated against clauses referenced by RequirementRole.
• An Approval SpeechAct (by a CAB chair who is a U.System) may transition RequirementRole: Draft → Approved. The Episteme does not “act”; Systems act, Epistemes hold status.

#Bias-Annotation

Lenses tested: Arch, Onto/Epist, Socio‑tech, Prag, Did. Scope: Kernel (A‑cluster).

• Architecture bias (Arch): treating roles/assignments as structural parts can smuggle function into mereology and break holarchies.
  Mitigation: keep roles out of BoM/structure trees; close windows instead of deleting history.

• Onto/Epist bias (Onto/Epist): anthropomorphising epistemes collapses evidence into agency (“the SOP approved”).
  Mitigation: only Systems enact Work; Epistemes may justify, constrain, and gate; enforce RE‑1 and CC‑SD‑2.

• Socio‑technical bias (Socio‑tech): role eligibility rules can silently encode exclusion, power asymmetries, or discrimination (e.g., “Approver must be X” with no rationale).
  Mitigation: keep eligibility refinements explicit in the Context, recorded as Episteme policy, and review them under D.2/D.* ethics patterns; prefer capability/competence evidence over demographic proxies.

• Pragmatic bias (Prag): over‑localising role labels can fragment reuse and create naming drift.
  Mitigation: require explicit :Context binding and explicit Bridges with CL/loss notes instead of silent equivalence.

• Didactic bias (Did): metaphors (“badge”, “mask”, “green gate”) may be misread as informal or security‑only.
  Mitigation: bind obligations to the Conformance Checklist; keep metaphors as mnemonic only.

#Conformance Checklist (normative)

#SCR (compact, memorable)

Pass these and your RoleAssignments are sound.

Anchoring & locality

1. CC‑CTX‑1. A conformant model/record MUST ensure that every RoleAssignment’s role names a role defined in the same U.BoundedContext as that assignment.
2. CC‑CTX‑2. Authors and validators MUST NOT assume cross‑Context equivalence by label; any cross‑Context relation used for substitution or checking MUST be represented only in Bridges (F.9).

Eligibility & families 3. CC‑ELIG‑1. Validators MUST reject any RoleAssignment record where role.family ∈ {Agential, Transformer, Observer, Speech} but holder :̸ U.System. 4. CC‑ELIG‑2. Validators MUST reject any RoleAssignment record where role.family ∈ {Epistemic‑Status, Normative‑Status, Service‑Governance} but holder :̸ U.Episteme. 5. CC‑ELIG‑3. Validators MUST reject any RoleAssignment record whose holder ∈ {U.Role, U.RoleAssignment} (no badge‑of‑badge chains).

Role algebra (in‑Context) See A.2.7 U.RoleAlgebra (CC‑ALG‑1, 2, 3).

Time & gating 9. CC‑WIN‑1. Record‑keeping systems and models MUST NOT delete historic RoleAssignment records; they close windows instead. If window is absent, the record MUST retain a traceable assignment start time (e.g., via a U.RoleAssigning SpeechAct Work or other evidence). 10. CC‑ENACT‑1. Conformant Work records MUST cite performedBy = some U.RoleAssignment; validators MUST be able to check that the Work interval fits the assignment window (or that an open‑ended window contains it). 11. CC‑ENACT‑2. At the Work time, validators MUST be able to (a) locate/derive a StateAssertion supporting an enactable RSG state for the cited assignment, and (b) verify that the assignment’s role satisfies the executed MethodStep’s requiredRoles in that same Context (directly or via ≤; ⊗ expands to conjunctions). 12. CC‑ENACT‑3. Runtime gates and validators MUST block enactment while the assignment lacks a supporting StateAssertion for an enactable state (e.g., during Suspended).

Strict distinction & category hygiene 13. CC‑SD‑1. Models and tools MUST NOT place Roles into BoM/structure trees; roles do not participate in mereology. 14. CC‑SD‑2. Models and tools MUST NOT treat Epistemes as Work actors; validators MUST enforce RE‑1 (by.holder : U.System).

Lexical hygiene 15. CC‑LX‑1. Authors MUST NOT use appointment as a synonym for Role Assignment in normative clauses.

Traceability 16. CC‑TRC‑1. From any U.Work, reviewers MUST be able to trace performedBy → RoleAssignment → Role → (RCS,RSG) → Context and retrieve supporting StateAssertion evidence.

#RSCR (regression harness)

Run these mental “diff checks” whenever you change roles, contexts, or states.

RSG & gating

• RSCR‑RSG‑E01. After editing an RSG, verify that each enactable state still has a live Conformance Checklist and that historic StateAssertions remain interpretable (no silent renames).
• RSCR‑RSG‑E02. If a state flips enactable⇄non‑enactable, re‑evaluate pending or recurring U.Work plans (no hidden authorisations).

SoD & windows

• RSCR‑SOD‑E01. On adding ⊥ constraints, scan for overlapping assignments that newly violate SoD; schedule revocations or rescheduling.
• RSCR‑SOD‑E02. On removing ⊥, confirm that governance rationale is recorded elsewhere (policy change Episteme).

Context churn

• RSCR‑CTX‑E01. When a Context edition updates, freeze prior RoleAssignments; create new assignments in the new Context rather than mutating old ones.
• RSCR‑CTX‑E02. Bridges referencing affected roles are reviewed for CL/loss adjustments.

Eligibility drift

• RSCR‑ELIG‑E01. If a role family changes (e.g., reclassifying Offerer from behavioral to status), audit all assignments for holder‑type violations.

Trace continuity

• RSCR‑TRC‑E01. Spot‑check that U.Work → RoleAssignment → StateAssertion chains still resolve after refactors.
• RSCR‑TRC‑E02. Randomly sample old incidents/runs to ensure reproducible authorisation verdicts.

Name stability

• RSCR‑NAME‑E01. If a role label changes, maintain the role identity; treat renamed labels as aliases inside the same Context rather than minting a new role unless RCS/RSG changed materially.

#Common Anti-Patterns and How to Avoid Them

#Consequences

Benefits

1. No type explosion. Structure stays stable; function lives in RoleAssignments with small, local lattices.
2. Traceable authority. Every U.Work has a clean chain: performedBy → RoleAssignment → Role → (RCS,RSG) → Context.
3. Safe heterogeneity. Different Contexts can use the same badge name differently; conflicts are dissolved by locality and explicit Bridges.
4. Didactic economy. One mental form — Holder#Role:Context@Window — covers factories, clouds, labs, and libraries.
5. Strong SoD. Incompatibilities (⊥) and bundles (⊗) are first‑class; audits become mechanical.
6. Assurance‑ready. RSG + StateAssertions convert checklists into explicit gates; CL penalties quantify Cross‑context risk.
7. Temporal honesty. Windows encode the ebb and flow of assignments without history loss.

Costs / discipline required

1. RoleDescription work. Each Context needs a minimal RoleDescription (name, RCS, RSG, checklists).
2. Bridge authorship. Cross‑context work requires explicit Bridges with CL & loss notes.
3. Vocabulary hygiene. Teams must stop using context‑less role labels.

#Teaching distillation (60‑second recap)

“Give every action a badge with a Context. The badge is a U.RoleAssignment: Holder#Role:Context@Window. The badge is valid in time (window) and green in state (RSG + StateAssertion). A Method step names the badges it needs; a Work cites the exact badge that enacted it. If a badge comes from another Context, cross with a Bridge and respect its CL penalty. Keep SoD with ⊥, reuse expertise with ≤, and require combos with ⊗. Documents don’t act — they hold status roles; only systems enact Work. With this, factories, clouds, and knowledge all speak the same, small grammar.”

#So what? Adoption test (1 minute)

If a team claims to “use A.2.1”, a random audit sample should pass all of these in minutes:

1. Badge locality: every role label is always read as Role:Context (or explicitly bridged), never as a global name.
2. Work attribution: each sampled U.Work cites a concrete performedBy = U.RoleAssignment, not just a person/system string.
3. Window + state gate: at the Work time, the assignment window fits and an enactable RSG StateAssertion exists (or the run is correctly blocked/exceptioned).
4. No badge‑of‑badge: no assignment ever binds a U.Role or U.RoleAssignment as its holder.
5. Status hygiene: no Episteme (Standard/Requirement/Evidence) is ever an actor of Work; it only gates/justifies/evaluates.

#Rationale

• Strict Distinction (A.7). Keeps identity (Holon) separate from assignment (RoleAssignment), behaviour (Method/Work), and knowledge (Episteme).
• Ontological Parsimony (A.11). One universal binding, three tiny in‑Context relations (≤, ⊥, ⊗), no global role types.
• Universal core (A.8). The same mechanism works across systems (machines, software, teams) and epistemes (standards, requirements), demonstrated in §5.
• Lexical discipline (E.10.D1 & E.10.D2). Roles are context‑local; descriptions (RCS, RSG) are descriptions of intensional roles, not the roles themselves.
• Assurance posture. Windows + RSG + StateAssertions make authorisation explicit and reviewable; Bridges + CL make cross‑Context reuse explicit and risk‑graded (B.3).

#SoTA-Echoing (notes)

#Relations

Builds on / depends on

• A.1 Holonic Foundation — U.Holon (holders).
• A.1.1 U.BoundedContext — the Context of meaning.
• A.2 Role Taxonomy — role kinds for Systems vs Epistemes; context‑local naming.
• A.2.7 U.RoleAlgebra — in‑Context ≤/⊥/⊗ relations used for substitution, SoD, and bundles.
• E.10.D1 (D.CTX) & E.10.D2 (Strict Distinction of intensional vs description) — locality & description discipline.

Enables / instantiated by

• A.15 Role–Method–Work Alignment — step gating, performer linking, evaluation hooks.
• B.1 Γ‑algebra — constructors/observers are simply roles enacted by systems.
• B.3 Trust & Assurance Calculus — CL penalties on Bridges; evidence from StateAssertions.
• D.2 Multi‑Scale Ethics — duties attach to roles; SoD encoded via ⊥.
• F‑cluster (Unification Method) — Context definitions (F.1–F.4) and Bridges (F.9) consumed here.

Interacts with

• C.* Patterns (Sys‑CAL, KD‑CAL, Method‑CAL, CHR‑CAL) — enactment hooks, measurement via Observations.
• Service & Deontics (Part D/E) — obligations and acceptance evaluated against role‑gated Work.

#A.2.1:End

#A.2.2 — U.Capability

#Context (plain‑language motivation)

In real projects we must answer two different questions:

• “Can this system do X?” — this is about an ability inherent to the system.
• “Is this system assigned to do X here and now?” — this is about an assignment (a Role assignment) inside a bounded context.

Teams frequently blur the two, and then further mix them with how the work is done (the Method) and what actually happened (the Work). U.Capability isolates ability as a first‑class concept so that you can plan realistically, staff responsibly, and audit cleanly.

#Problem (what goes wrong without this concept)

1. Permission ≠ ability. A Role assignment authorizes execution in a context; it does not prove the system can meet the required WorkScope and WorkMeasures.
2. Recipe ≠ ability. A Method says how to do something; it does not guarantee that this holder can meet the target outcomes under the required constraints.
3. Execution log ≠ ability. A past Work record does not, by itself, establish a stable ability; conditions may have been favorable or unique.
4. Cross‑team confusion. Enterprise terms like “capability”, “service”, and the old “function” are used interchangeably; planning, staffing, and assurance become fragile.

#Forces (what we must balance)

#Solution — define the ability explicitly

#A.2.2:4.1 Definition

U.Capability is a dispositional property of a U.System that states its ability to produce a class of outcomes (i.e., execute a class of Work) within a declared U.WorkScope (conditions/assumptions) and meeting stated U.WorkMeasures. It is not an assignment (Role), not a recipe (Method), and not an execution (Work).

One-liner to remember: Capability = “can do (within its WorkScope and measures)”, independent of “is assigned now” or “did do at time t”.

Capability declaration (summary). A capability SHALL declare, as separate items:

• U.WorkScope (Work scope) — the set of U.ContextSlice under which the capability can deliver the intended U.Work (see A.2.6 §6.4);
• U.WorkMeasures — measurable targets with units evaluated on a JobSlice (R‑lane facet);
• U.QualificationWindow — the time policy that governs operational admissibility at Γ_time (R‑lane facet). Note. This separation supersedes the legacy “envelope + measures + validity interval” bundle. Work scope is the set of conditions (USM), not a Characteristic; measures are CHR‑characteristics; capability packages both.

Reminder (measurement & scope). WorkScope is a set‑valued USM object (membership, set algebra) and not a CHR Characteristic; WorkMeasures are CHR Characteristics with declared scales/units. Admission checks these separately (see § 10.3 WG‑2/WG‑3).

#A.2.2:4.2 Conceptual descriptors (not a data schema)

When you describe a capability in a model or a review, anchor it by answering these five didactic prompts:

1. Holder: Whose ability is this? → a specific U.System.
2. Context: In which bounded context were the measures established? → U.BoundedContext (strongly recommended for clarity and comparability).
3. Task family: Ability to do what kind of work? → reference the relevant MethodDescription(s) or method family the system can execute.
4. WorkScope: Under what conditions? → inputs/resources/environment assumptions (e.g., voltage, pressure, ambient, tool head).
5. Performance measures: With what bounds? → CHR‑style measures (throughput, precision, latency, reliability, MTBF…) with ranges/targets.

Optional descriptors that improve trust without adding bureaucracy:

• QualificationWindow: calibration/qualification window for the stated WorkScope (abilities drift).
• Evidence: links to test reports, certifications, prior Work summaries (as Episteme).
• Degradation/upgrade notes: known change points that affect the WorkScope.

Didactic guardrail: Capabilities are stated in positive, measurable terms (“can weld seam type W at ±0.2 mm up to 12/min at 18 °C–30 °C”). Avoid role words (“welder”) or recipe detail (step flows) here.

#A.2.2:4.3 Shorthand for everyday speech

To keep discussions terse yet precise, teams often write:

• “S#17 can <MethodDescription / task family> @ <WorkScope> → <measures>.”
• Or as a bullet in a capability table scoped to a context, e.g., AssemblyLine_2025 Capability Sheet.

This is not a formal notation—just a consistent way to keep the five prompts in view.

#Clear distinctions (litmus tests managers can apply)

Two useful corollaries

• A step in a Method may require a Role; optionally it may also stipulate a capability threshold (e.g., precision ≤ 0.2 mm). assignment and ability are checked separately.
• A promise content clause depends on having the needed capabilities and being assigned/committed to deliver under the clause’s context (bind as U.Commitment when it is an obligation).

#Archetypal grounding (parallel structural and organizational examples)

#A.2.2:6.1 Physical system on a line (structural example)

• Holder: RobotArm_A (U.System).
• Task family: seam welding per Weld_MIG_v3 MethodDescription.
• WorkScope: workpiece steel grades S235–S355; ambient 18–30 °C; argon mix 92–95 %; torch T‑MIG‑07.
• Measures: bead width 6.0 mm ± 0.2 mm; throughput ≤ 12 seams/min; defect rate < 0.5 %.
• Context: AssemblyLine_2025.
• Readable claim: RobotArm_A can execute Weld_MIG_v3 within the stated WorkScope at the stated measures (AssemblyLine_2025).
• What this is not: It is not “the welder”—that is a Role assignment when assigned on a shift. It is not the weld recipe— that is the MethodDescription.

#A.2.2:6.2 Software service in operations (structural, cyber-physical)

• Holder: PlannerService_v4 (deployed system).
• Task family: job‑shop schedule generation per JS_Schedule_v4 MethodDescription.
• WorkScope: 50–500 jobs; 5–40 machines; hard deadlines only; network latency ≤ 20 ms.
• Measures: schedule completion within 0.95 of theoretical optimum (benchmark set), 98 % on‑time delivery in simulation.
• Context: PlantScheduling_2025.
• Use: Steps that “require ScheduleGeneration capability ≥ 0.90 optimality” will only pass if the holder’s capability meets or exceeds that bound.

#A.2.2:6.3 Organizational unit (enterprise sense)

• Holder: FinanceDept (U.System as OrgUnit).
• Task family: period close per CloseBooks_v3 MethodDescription.
• WorkScope: IFRS; ERP v12; 8 legal entities; staffing ≥ 6 FTE; cut‑off rules X.
• Measures: close in ≤ 5 business days; adjustment error rate < 0.2 %.
• Context: OperatingModel_2025.
• Distinction: This is ability; the service promise clause “Provide month‑end close” is the external promise derived from this ability once formally offered.

#Bias‑Annotation (as in cluster‑E patterns)

• Lenses tested: Arch, Prag, Did, Epist.
• Scope declaration: Universal; holder constrained to U.System.
• Rationale: Gives the kernel a clean, reusable ability concept so Role (assignment), Method (recipe), Work (execution), and promise content (external promise clause) do not collapse into each other. Keeps planning talk truthful and checkable without introducing governance machinery here. U.Capability is a dispositional property of a U.System that states its ability to produce a class of outcomes (i.e., execute a class of Work) within a declared U.WorkScope (conditions/assumptions) and meeting stated U.WorkMeasures.

#Conformance Checklist (normative)

CC‑A2.2‑1 (Holder type). A capability belongs to a U.System (physical, cyber, socio‑technical, or organizational). Capabilities are not assigned to U.Episteme.

CC‑A2.2‑2 (Separation of concerns). A capability is not a Role, not a Method/MethodDescription, not a Work, and not a promise content clause (U.PromiseContent). Models SHALL NOT use capability declarations to stand in for assignments, recipes, executions, or promises.

CC‑A2.2‑3 (WorkScope required for operational use). When a capability is used to qualify a step or to support planning, its statement MUST name a WorkScope (conditions/assumptions) and WorkMeasures (targets/ranges). Guards that admit Work MUST test that the holder’s WorkScope covers the step’s JobSlice (i.e., WorkScope ⊇ JobSlice) and that WorkMeasures meet the step’s thresholds, with an explicit Γ_time window bound. Without a WorkScope and measures, a capability is advisory and SHALL NOT be used for step admission or assurance claims.

CC‑A2.2‑4 (Context anchor). Capability statements that drive operational decisions MUST be anchored to a U.BoundedContext (the “Context” whose vocabulary and test norms apply).

CC‑A2.2‑5 (QualificationWindow). When capabilities are used operationally (e.g., to gate Work), the statement MUST carry a QualificationWindow (calibration window, software version window, etc.) and the guard MUST name the Γ_time window used for the check. Outside the QualificationWindow, the claim is not admissible for gating.

CC‑A2.2‑6 (Past work remains past). Updates to a capability statement SHALL NOT retroactively invalidate already recorded Work. Past Work is judged against the capability declaration that was valid at the time of execution.

CC‑A2.2‑7 (Threshold checks are orthogonal to roles). A step that requires both a Role and a capability threshold admits a Work only if both are satisfied: (i) the performer’s Role assignment is active in the step window; (ii) the holder’s capability meets or exceeds the threshold with WorkScope ⊇ JobSlice and within the QualificationWindow at the named Γ_time.

CC‑A2.2‑8 (Derived capabilities). If a capability is claimed for a composite system (assembled by Γ), the claim MUST be stated as a property of that composite holder (not of its parts) with clear dependency notes (e.g., “valid while Subsystem B meets X”). Details of derivation belong to the context’s methodology, not to this definition.

CC‑A2.2‑9 (No capability for epistemes). Algorithms, standards, and documents provide evidence or recipes; they do not “have capability.” Only systems do.

CC-A2.2-10 (Γ_time selector in guards). Scope-sensitive guards (including Method–Work gates) MUST include an explicit Γ_time selector indicating the window W over which ScopeCoverage and WorkMeasures are evaluated.

#Capability thresholds on steps (how A.15 uses this concept)

A step in a Method may define required roles (assignment) and capability thresholds (ability). A Work passes the gate if:

1. assignment check: the Work’s performedBy points to a valid Role assignment that covers the step window and satisfies the role relation (including specialization ≤ inside the context).
2. Ability check: the holder of that Role assignment has a capability whose WorkScope covers the step’s JobSlice (i.e., declared superset) and whose WorkMeasures meet the step’s threshold(s) within Γ_time(W) and while the capability’s QualificationWindow includes W.

Idioms managers can reuse (plain text):

• “S1 requires IncisionOperatorRole and Precision ≤ 0.2 mm (OR_2025 norms) in window W.”
• “S2 requires PlannerRole, WorkScope ⊇ JobSlice[W], and Optimality ≥ 0.90 on JS_Schedule_v4.”

What to avoid:

• Putting “Precision ≤ 0.2 mm” into the Role name. Keep thresholds attached to the step; keep ability on the holder.

#Time and change (calibration, drift, upgrades)

Capabilities are stable but not static. Three simple practices keep reasoning honest:

• Qualification windows. Abilities drift. Put a QualificationWindow on the statement (e.g., “valid for software v4.2; recalibration due 2025-09-30”).
• Change points. Note upgrades/downgrades that affect the WorkScope or measures.
• Snapshot at execution. When Work is recorded, it is implicitly tied to the then‑current capability statement; later edits do not rewrite history (see CC‑A2.2‑6).

Manager’s rule of thumb: if you would reschedule a job after a tool change, the capability statement needs a new window.

#Composition and Γ (how assembled systems “can do”)

Γ builds a new holder (a composite system). Its capability is not the algebraic sum of parts; it is an ability of the whole under its own WorkScope.

• Express at the whole. “Cell_3 can place 12 PCB/min with ±0.1 mm” — that is a capability of Cell_3, not of the pick‑and‑place head alone.
• State dependencies. “Valid while Feeder_A delivers reels at ≥ X; vision subsystem calibrated ≤ 72 h ago.”
• Constructor vs. transformer. The ConstructorRole builds the composite (Γ); the resulting TransformerRole may later act on products. Capability belongs to the holder relevant to the action (builder’s ability vs operator’s ability).

#Interaction with Service Promise Clauses (external promise content)

A service promise clause (a U.PromiseContent) is a consumer‑facing external promise statement. It relies on capability but is not identical to it.

Note. The bare head noun service is polysemic; in normative prose it is treated as an always‑unpack token. Use A.6.8 (RPR‑SERV) to name the intended facet (promise clause vs endpoint vs work vs commitment).

• From capability to service promise clause. You normally derive a service promise clause by taking a capability and fixing the promise outward (e.g., “We guarantee close ≤ 5 days”).
• From service promise clause back to capability. If the promise raises the bar (e.g., tighter SLA), the underlying capability must meet or exceed it under the promise clause’s context.
• Staffing. Delivering on a service promise clause still requires Role assignments; capability alone does not authorize action.

Memory aid: Capability = can do; service promise clause = promise to others that we will do.

#Interaction with Dynamics (laws vs. abilities)

• Dynamics describe how states evolve (models, laws, trajectories).
• Capability says what this system can achieve within an WorkScope.
• Dynamics often serve as evidence or explanatory models for capability but are not the capability itself.

Physics example: an “isothermal process” (process here as transformation) is a Work instance whose path is explained by a Dynamics episteme; a lab rig’s ability to run that path repeatably is its capability.

#Anti‑patterns (and the right move)

• Role‑as‑capability. “Welder role ensures ±0.2 mm.” → Keep role as assignment; put precision in a capability on the holder; put the threshold on the step.
• Recipe‑as‑capability. “We have the ‘Etch_Al2O3’ capability.” → Recipe is Method/MethodDescription; ability is “can execute Etch_Al2O3 within WorkScope E at measures M.”
• Work‑as‑capability. “We did it once, so we can.” → One Work log is not a stable ability; state envelope and measures if you want a capability claim.
• Context‑less claims. “This tool can machine titanium.” → Say where and under what bounds (context + WorkScope + measures).
• Stuffing capabilities into BoM/PBS. Structure lists what it is; capabilities belong to what it can do (the holder), not inside the parts list.
• Service‑as‑capability. “We have the Month‑end Close capability (promise).” → Promise is a service promise clause (U.PromiseContent); ability is internal, promise is external.

#Migration notes (quick wins for existing texts)

1. Underline WorkScopes. For every “can do” sentence, add conditions and measures; otherwise treat it as background color, not a gate.
2. Pull thresholds out of roles. Move “≤ 0.2 mm”, “≥ 0.90 optimality” from role labels into step requirements; leave roles clean (assignments).
3. Pin contexts. Add the bounded context name to each capability table (“Capability Sheet — AssemblyLine_2025”).
4. Snapshot validity. Add a “valid through” column (software version or calibration horizon).
5. Separate recipe/execution. Move flowcharts under MethodDescription, runs under Work; link the capability to the holder with references to those specs.

#Consequences

#Relations

• Builds on: A.1 Holonic Foundation; A.1.1 U.BoundedContext; A.2 Role; A.2.1 U.RoleAssignment.
• Coordinates with: A.3 (Transformation & role masks); A.15 (Role–Method–Work Alignment).
• Constrains: Step design: thresholds belong on steps; BoM/PBS must stay structural.
• Informs: U.PromiseContent definitional pattern (external promises derive from capabilities); U.Dynamics definitional pattern (models used as evidence or predictors); Γ/aggregation (capability of composites is stated at the whole).
• Lexical guards: E.10.x L‑FUNC (do not call capability “function”); E.10.y L‑PROC (do not call capability “process”).

#Didactic quick cards (reuse in specs and slides)

• Capability = can do (within bounds). assignment ≠ ability ≠ recipe ≠ execution ≠ promise.
• Gate every critical step with two checks: badge (Role assignment) + bounds (Capability).
• Write the Context on every claim: context name, WorkScope, measures, QualificationWindow/valid-through.

#A.2.2:End

#U.PromiseContent (Promise Content)

#Context

Across domains the word service is used for many different things: a server or provider, an API, a procedure, a run, a department, even a product bundle. Such polysemy is productive in everyday speech but toxic in a normative model.

FPF therefore reserves U.PromiseContent for exactly one kernel meaning: promise content — a promise content (a consumer‑facing promise statement). Any other “service” sense MUST be modeled explicitly as U.System, U.RoleAssignment/principal, U.MethodDescription, or U.Work inside an appropriate U.BoundedContext and, in normative prose, MUST be written with an explicit facet head phrase per A.6.8 (RPR‑SERV).

This keeps the kernel minimal while keeping the prose readable to non‑mathematicians: the canonical symbol is U.PromiseContent, and the head kind in normative text is always promise content.

Modularity note. A.2.3 defines only the promise‑content object (the promise content) and its direct links to roles, access specification, acceptance criteria, and work evidence. The multi‑facet “service situation” bundle that also names provider principals/systems/access points/commitments/acts is handled as a precision‑restoration lens in A.6.8 (serviceSituation(…)). Contract‑talk unpacking (and routing of “contract / SLA / guarantee” language) is handled by A.6.C, which calls A.6.8 when service‑cluster tokens appear.

In the Role–Method–Work alignment, the promise content must say something external‑facing and consumer‑oriented, yet remain separate from how the provider does it (Method/MethodDescription) and what actually happened (Work).

Intuition: the consumer-facing promise clause is what you advertise and are judged by (U.PromiseContent); work is what you do to keep that promise; method/spec is how you know what to do. (See A.6.8 for full “service” polysemy unpacking.) (Normative head-kind rewrite): a promise content is the promise clause you advertise and are judged by; work is what you do (and what can be evidenced) to satisfy that promise; method/spec is how you know what to do.

Lexical note (L‑SERV / RPR‑SERV)

The surface forms service/service‑level/service use/service access (and the adjacent cluster service provider, server) are ambiguous across domains. In the kernel, U.PromiseContent is reserved for promise content only and is written in prose as a promise content.

Normative prose therefore SHALL treat the bare head noun service as always‑unpack (PTG=Guarded): every head‑noun occurrence MUST be rewritten to a facet head phrase (promise content / service provider principal / service access point / service delivery system / …) or to the correct underlying FPF object (team, ticket, endpoint host, procedure, work item), per A.6.8 (RPR‑SERV).

E.10’s lexical anchor L‑SERV SHOULD be implemented as “pointer + lint rule” to A.6.8: the short rule names the hazard, while A.6.8 provides the full rewrite recipe and the facet head phrase set.

#Problem

Without a first‑class U.PromiseContent, models drift into five recurring errors:

1. Provider = Service. Calling the system or team “the service” collapses structure with promise.
2. API = Service. Treating an interface/endpoint as the service hides the consumer‑oriented promise (effect + acceptance).
3. Process = Service. Mapping a procedure/Method (or a WorkPlan) to “service” confuses recipe/schedule with the external commitment.
4. Run = Service. Logging Work as “a service” erases the Standard/promise layer and breaks SLA reasoning.
5. Business ontology lock‑in. Large domain schemes (e.g., “business service” stacks) are imported wholesale, losing FPF’s universality and comparability across contexts.

#Forces

#Solution — The unified concept U.PromiseContent

Definition (normative). Within a U.BoundedContext, a U.PromiseContent is an externally oriented promise clause: a context‑local statement of (i) a promised external effect, (ii) eligibility + access (how a consumer may request/use), and (iii) acceptance criteria (SLO/SLA‑like targets) by which fulfillment is judged.

U.PromiseContent is promise content (U.Episteme), not a deontic binding. One or more explicit U.Commitment objects (A.2.8) MAY reference a U.PromiseContent as payload to bind an accountable principal/role‑assignment; the clause itself does not “obligate” anyone until such a commitment is represented.

In normative prose, the head phrase for U.PromiseContent is promise content (or service offering clause / service promise clause) per A.6.8; the bare noun service is not a valid shorthand for this kernel object.

• Type: U.Episteme (a promise clause on a carrier).
• Scope: design‑time concept; judged at run‑time by evidence from U.Work.
• Time stance: design-time concept; judged at run-time by evidence from U.Work.
• Orientation: consumer‑facing (“what you can rely on”), as opposed to capability (“what we can do”).
• Prose head (normative): promise content (Tech) / service offering clause (Plain; service promise clause acceptable synonym). (Both twins retain an explicit clause head‑kind to avoid act/content ambiguity and to comply with A.6.8 headword governance.)

#Core structure (minimal fields)

U.PromiseContent {
  context        : U.BoundedContext,   // where the promise is meaningful
  purpose        : Text/Episteme,      // the externally observable effect/value
  providerRole   : U.Role,             // role kind that may provide it (not a person/system)
  consumerRole?  : U.Role,             // optional role kind allowed to consume
  claimScope?    : U.ClaimScope,       // where the promise holds (G) — operating conditions/populations/locales
  accessSpec?    : U.MethodDescription,       // service access spec: request-facing interface/eligibility; not an access point system
  acceptanceSpec : U.Episteme,         // targets: SLO / acceptance targets (quality/throughput/latency/accuracy…); evaluated over same evidence base as promisedOutcomeSpecRef (CC‑A2.3‑18)
  promisedOutcomeSpecRef : OutcomeSpecRef, // promised outcome (work, result, or both) in disambiguated spec form
  unitOfDelivery?: Episteme,           // how delivered units are counted/measured (unit + countingRule; see A.7:5.10)
  version?       : SemVer/Text,
  timespan?      : Interval
}

• promisedOutcomeSpecRef MUST point to a U.OutcomeSpec (A.7:5.10). It is the promise‑facing outcome template (work‑only / result‑only / composite), not a U.Work episode and not an extensional delivered object.
• providerRole and consumerRole are role kinds; the actual performers are RoleAssignments at run‑time.
• acceptanceSpec defines what counts as fulfilled (the test).
• accessSpec is how to ask (eligibility, protocol, counter, desk, API).
• Internal delivery methods/runbooks are not part of the promise content. Model them as U.MethodDescription and relate them to the clause via serviceSituation(…) (A.6.8) or explicit context relations; providers retain Method autonomy.

#Promised outcome spec (disambiguation: work vs post-work result)

promisedOutcomeSpecRef points to an U.OutcomeSpec episteme that makes explicit what exactly is promised — in kind/spec form — without collapsing it into either:

• the promise content clause itself (U.PromiseContent),
• the delivery work that happens at run‑time (U.Work), or
• the resulting state/object after the work.

This is a controlled semantic precision restoration for the everyday metonymy “outcome/service outcome”, which different communities use to mean (i) the work performed, (ii) the achieved result, or (iii) both.

Terminology bridge (informative). In loose contract talk people say promiseOutcomeSpec (the description of what will be delivered) and promiseOutcome (what was actually delivered). Those surface forms are metonymic: sometimes they mean “the work performed”, sometimes “the post‑work result”, and sometimes the pair.

In FPF:

• promiseOutcomeSpec → U.OutcomeSpec (A.7:5.10), referenced via promisedOutcomeSpecRef.

• promiseOutcome → an extensional delivered outcome instance. It is not a single kernel object; it is the run‑time reality that satisfies the outcome spec, understood according to U.OutcomeSpec.mode:

  • WorkOnly → the set of delivery U.Work episode(s) that satisfy workSpec (and, if present, the promised methodConstraintRef).
  • ResultOnly → the post‑work state of the described referent(s) on the declared statePlaneRef that satisfies resultSpec.postConditionRef (regardless of how it was achieved).
  • Composite → the pair: (delivery Work episode(s), post‑work state).

  FPF points to this extensional delivered outcome instance by citing: (i) the relevant U.Work occurrence(s) and (ii) their Δ anchors (affected referents + pre/post anchors) on the declared state‑plane (A.15.1:4.2 item 10). Evidence carriers/telemetry are epistemic witnesses used to justify those anchors and acceptance verdicts—they are not themselves the delivered outcome.

If a Context needs an explicit handle for the delivered instance (e.g., for bundling, invoicing, or dispute cases), it MAY introduce a local kind such as OutcomeInstance with separate slots for: {workRefs, affectedEntityRefs, postStateAnchors, evidenceRefs}. Such a local reification MUST keep (a) the extensional delivered instance, (b) the evidence about it, and (c) the outcome spec (U.OutcomeSpec) distinct.

A conforming U.OutcomeSpec uses the canonical shape from A.7:5.10.2:

U.OutcomeSpec ::= {
  mode: WorkOnly | ResultOnly | Composite,

  workSpec?: {
    methodConstraintRef?: MethodDescriptionRef,   // optional: method is part of the promise (not “implementation detail”)
    workPredicateRef: EpistemeRef                 // predicate on `U.Work` facts/evidence
  },

  resultSpec?: {
    describedEntityRef?: EntityRef,               // what thing’s post‑state matters (may be kind‑labelled)
    statePlaneRef?: StatePlaneRef,                // where the predicate lives (A.7:3 pins)
    postConditionRef: EpistemeRef                 // predicate on post‑state (or evidence about it)
  }
}

• workSpec corresponds to the work‑as‑promised facet: it states the consumer‑facing kind of work (optionally constraining method) and the work predicate (e.g., duration, method ban, safety bound).
• resultSpec corresponds to the result‑as‑promised facet: it states the post‑work entity/state kind and the postcondition predicate.
• Counting is not part of U.OutcomeSpec. Counting lives on U.PromiseContent.unitOfDelivery as the countingRule mini‑schema (A.7:5.10.3). Outcome specs say what counts as delivery; unit‑of‑delivery specs say how much to count and how to avoid double counting.

Examples (informative):

• “Work 5 minutes” → mode=WorkOnly; workPredicateRef states duration ≥ 5 min; methodConstraintRef may be omitted.
• “Dig a hole” → mode=ResultOnly; postConditionRef describes the hole’s target state; method choice remains provider‑autonomous.
• “Hairstyle in ≤ 20 min, must be haircut+styling (not a wig)” → mode=Composite; workSpec expresses time + method constraint; resultSpec expresses the target hairstyle state.

Naming note (normative). The head noun outcome is intentionally broad. Do not replace it with result when referring to the combined promise payload. If a passage means the post‑work entity/state only, say result and bind it to resultSpec. If it means the work episode(s) promised, say work as promised and bind it to workSpec.

#Recommended acceptanceSpec mini‑schema (informative, non‑kernel)

acceptanceSpec : U.Episteme is intentionally open‑ended in Core. However, to keep acceptance computable (and to avoid the legacy “pass verdict separate from delivery” mistake), Contexts are encouraged to express acceptanceSpec as a small bundle of references:

AcceptanceSpec (recommended) ::= {
  targetOutcomeSpecRef?: OutcomeSpecRef,  // default: SC.promisedOutcomeSpecRef
  criteriaRefs: [EpistemeRef],            // each criterion evaluates the *delivery evidence base* (U.Work facts + Δ anchors + admissible Observations)
  verdictScale: Episteme/ScaleRef,        // pass/fail/graded; MUST state how “non‑delivery” is represented
  Γ_timePolicyRef?: EpistemeRef           // how Γ_time is selected (per‑Work, per calendar window, per batch, per population, …)
}

• targetOutcomeSpecRef makes explicit which promised outcome is being judged; if omitted, it is the containing promise content’s promisedOutcomeSpecRef.
• criteriaRefs are the acceptance criteria (SLO targets, quality gates, compliance predicates, etc.). Each criterion is an evaluation over the same evidence base used to establish delivery of the targeted U.OutcomeSpec: U.Work facts/evidence plus the relevant Δ anchors (affected referents + pre/post anchors) on the declared state‑plane, and any admissible U.Observation witnesses.
• verdictScale declares the decision scale (boolean, trichotomy, graded). It MUST define what happens when the outcome is not delivered (e.g., fail, N/A, Inconclusive, or a dedicated grade).
• Γ_timePolicyRef keeps windowing explicit and non‑retroactive (F.10/F.12): it states whether judgement is per Work episode, per reporting window, per population, etc.

This mini‑schema is a recommendation only: it is not a kernel object and may be flattened, encoded in a canonical SLO vocabulary, or carried in local contract artefacts. Its purpose is to keep acceptance discussable, auditable, and bridge‑ready.

#What U.PromiseContent is not

• Not a provider: use System#ServiceProviderRole:Context U.RoleAssignment.
• Not a deontic commitment: that is U.Commitment (A.2.8) referencing the promise content as payload.
• Not an access point: addressable “services/servers/desks/endpoints” are U.System (see A.6.8: service access point / service delivery system).
• Not a method/recipe: that is U.Method/MethodDescription.
• Not a run/incident/ticket: that is U.Work.
• Not a schedule: that is U.WorkPlan.
• Not a capability: capability is provider‑intrinsic ability; service is outward promise. A service may require certain capabilities, but it is not the capability.
• Not a scope label: do not use applicability, envelope, generality, or validity as names for scope objects; declare Claim scope (G) or Work scope explicitly where needed (A.2.6).

#Position in the enactment chain

• Design‑time: The context declares Claim scope (G) for acceptance (operating conditions, populations, locales) per A.2.6. The context may assert: bindsCapability(ServiceProviderRole, Capability). Providers choose Method/MethodDescription to realise the promised effect described by the promise content.

• Run‑time: A consumer performs Work (e.g., a request/visit) — performedBy: ConsumerRoleAssigning. The provider performs Work to fulfil the promise content — performedBy: ProviderRoleAssigning. Delivered Work instances are evaluated against acceptanceSpec, linked to promisedOutcomeSpecRef, and counted via unitOfDelivery. SLA/SLO outcomes are therefore functions over Work evidence, not over the promise content object itself.

  (Terminology note: use …RoleAssignment consistently for the run‑time enactor relation; avoid the “RoleAssigning” variant unless it is a separately defined kind in the Context.)

Memory hook: Promise content promises, Method describes, Work proves.

#Didactic card: The service delivery chain (clause → commitment → situation → work → acceptance)

Didactic (non‑normative). This is a one‑screen “map” that stitches the modular pieces together: U.PromiseContent (A.2.3) → U.Commitment (A.2.8) → provider U.RoleAssignment (A.2.1) → serviceSituation(...) facet slots (A.6.8 lens) → U.Work + carriers (A.15) → acceptance verdict (A.2.3).

This is not new ontology. It is a reader‑safety diagram that prevents two common category errors: (i) treating U.PromiseContent as something addressable (“the service you call”), and (ii) treating serviceSituation(...) as semantics rather than a binding lens over already‑defined kinds.

flowchart LR
  SC["Promise content<br/>(U.PromiseContent · Episteme)"]
  C["Commitment<br/>(U.Commitment · D)"]
  RA["Provider role assignment<br/>(U.RoleAssignment · accountable subject in Context/window)"]

  subgraph LENS["Optional lens (A.6.8): serviceSituation(...)"]
    AS["Access spec<br/>(U.MethodDescription · request‑facing)"]
    AP["Access point<br/>(U.System · addressable)"]
    DS["Delivery system<br/>(U.System · realizer)"]
    DM["Delivery method<br/>(U.MethodDescription · runbook/procedure)"]
  end

  W["Work + evidence<br/>(U.Work + carriers · E)"]
  V["Acceptance verdict<br/>(pass/fail/grade; computed)"]

  SC -->|"payload/ref"| C
  C -->|"binds subject"| RA

  RA --> AS
  RA --> AP
  RA --> DS
  RA --> DM

  AS -->|"invoked via"| W
  AP -->|"requests arrive via"| W
  DS -->|"fulfillment work"| W
  DM -->|"procedure used in"| W

  W -->|"evaluate"| V
  SC -->|"acceptanceSpec"| V

Reading guide (one breath).

• The promise content is what is promised (promise content).
• The commitment is who is bound (deontic accountability) and it references the clause.
• The provider role assignment is the accountable subject that can act in a given Context/window.
• serviceSituation(...) (A.6.8) is a facet‑binding lens that names the common “service talk” participants (access spec / access point / delivery system / delivery method) without collapsing them into the clause.
• Work + evidence is what happened; the acceptance verdict is computed by applying the clause’s acceptanceSpec to work evidence (not by reading the clause, and not by “looking at the service” as a system).

Litmus rule (addressability). If you can call / connect to / visit / restart / scale it, you are talking about a service access point (system facet), not the promise content (promise content).

#Archetypal grounding (engineer‑manager friendly)

Key takeaway: the same kernel object models S3, a plant utility, and a government service: a promise with access and acceptance. Everything else (APIs, compressors, clerks, workflows, tickets) is mapped via Role/Method/Work.

#Mapping the common “service” picture to FPF (didactic bridge)

The popular service diagrams (provider ↔ access ↔ use ↔ capability/activity) map to FPF as follows:

• Agent (as Service Provider) → System#ServiceProviderRole:Context (U.RoleAssignment).

• Service Level Objective (SLO) / acceptance targets → U.PromiseContent.acceptanceSpec (+ optional WorkPlan for windows).

• Service Level Agreement (SLA) (binding obligation) → U.Commitment referencing the relevant U.PromiseContent (and, where needed, its acceptance/evidence specs); use A.6.C Contract Bundle when packaging “the SLA” as an artefact set.

• SLA document / published terms → U.SpeechAct (promise/offer act) + the clause carrier (U.Episteme), per A.2.9 + A.7.

• Operating conditions / “where the promise holds” → claimScope : U.ClaimScope (G) (or embedded in acceptanceSpec) per A.2.6.

• Subject of service (“customer material”: asset/data/person/case whose state is changed) → promisedOutcomeSpecRef.resultSpec.describedEntityRef (and the affected referents in delivery U.Work.Δ). “Ours vs theirs” (ownership/custody) is modeled as a role/relationship inside the Context (e.g., OwnerRole:…, CustomerRole:…, operated‑by/owned‑by), not as a Kernel‑global property.

• Service Presence / Access → accessSpec : MethodDescription (interface/eligibility); actual endpoints are systems playing interface roles.

• Individual Service Use → consumer and provider U.Work instances linked to the U.PromiseContent they fulfil.

• Service‑Enabled Capability / Activity → effects on the consumer side: either a Capability gained/used, or Work performed; do not reify as a new kernel type.

(Where a domain needs richer structures—catalogs, exposure layers, charging, entitlement—model them in the domain context and relate them to U.PromiseContent via U.RoleAssignment and alignment bridges.)

#Conformance Checklist (normative)

CC‑A2.3‑0 (Prose head phrase). In normative prose, an instance of U.PromiseContent SHALL be referred to as a promise content (or service offering clause / service promise clause) and SHALL NOT be referenced by the bare head noun service. Unqualified service usage (and the co‑moving cluster service provider / server) SHALL be unpacked per A.6.8 (RPR‑SERV).

CC‑A2.3‑1 (Type). U.PromiseContent IS an U.Episteme (a consumer‑facing promise content on a carrier). It is not a U.System, not a U.Method/MethodDescription, not a U.Work, and not a U.WorkPlan.

CC‑A2.3‑2 (Context). Every promise content MUST be declared inside a U.BoundedContext. Names and meaning are local; cross‑context reuse requires a Bridge (U.Alignment).

CC‑A2.3‑3 (Role kinds, not people/systems). providerRole and (if used) consumerRole MUST be role kinds (see A.2). Actual performers at run‑time are U.RoleAssignments.

CC-A2.3-4 (Acceptance). acceptanceSpec MUST be present and MUST define how delivered U.Work is judged (pass/fail/graded) against declared targets (SLO‑style; any SLA deontics bind via U.Commitment), and MUST declare Claim scope (G) where relevant (operating conditions, populations, locales). Every verdict binds to an explicit Γ_time window. If the acceptance criteria mention measurable characteristics (availability, latency, accuracy, cost, safety, …), each such characteristic MUST be introduced via the Characterization patterns (C.16 / C.25): an explicit U.Characteristic (with scale/unit and measurement procedure / evidence carrier), referenced by id rather than only by a bare KPI name.

CC‑A2.3‑5 (Access). If consumers must request/obtain service delivery work through a request‑facing interface, accessSpec MUST reference the MethodDescription that defines eligibility and invocation rules (API/desk/SOP). If the service access point is ambient (e.g., compressed air on a manifold), accessSpec MAY be omitted, but the eligibility condition MUST be stated in the Context.

CC‑A2.3‑6 (Unit of delivery + counting rule). If performance is counted/charged, unitOfDelivery SHOULD be declared (e.g., “request”, “kWh”, “case”). When declared, unitOfDelivery MUST include a countingRule that maps accepted delivery work episodes (W✓) to unit counts (A.7:5.10). If omitted, the default is “1 unit per accepted delivery work episode”.

CC‑A2.3‑7 (No actuals on Promise Content). Resource/time actuals and incident logs MUST attach to U.Work only (A.15.1). Promise contents carry no actuals.

CC‑A2.3‑8 (Capability requirement). If the context requires provider abilities, it MUST express them as bindsCapability(providerRole, Capability) in the context, not by stuffing capabilities into the Service object.

CC‑A2.3‑9 (Versioning & timespan). Promise contents MAY carry version/timespan. A U.Work that claims/fulfils a promise content MUST record which service‑clause version it used.

CC‑A2.3‑10 (Lexical rule). Unqualified head‑noun uses of service (and the co‑moving cluster service provider / server) in normative prose MUST be disambiguated per A.6.8 (RPR‑SERV) and its lexical anchor L‑SERV (E.10).

CC‑A2.3‑11 (No mereology). Do not place a promise content clause in PBS/SBS or treat it as a part/component. Structural assemblies live in PBS/SBS; the promise clause is an episteme (A.2.3) and “service” talk must be facet‑unpacked (A.6.8).

CC‑A2.3‑12 (Plan–run split). Windows and calendars belong to U.WorkPlan (A.15.2). Fulfilment evidence belongs to U.Work (A.15.1).

CC-A2.3-13 (Scope lexicon & guards). Deprecated labels applicability/envelope/generality/validity MUST NOT appear as names for scope objects in guards or conformance blocks. Use U.ClaimScope (G) for epistemes and U.WorkScope for capabilities (A.2.6/A.2.2). Scope-sensitive guards MUST use ScopeCoverage with explicit Γ_time selectors.

CC-A2.3-14 (Bridges & CL). Cross-context mappings via Bridges keep F/G stable; CL penalties apply to R. A mapping MAY recommend narrowing the mapped Claim scope (G) as best practice (A.2.6/B-line).

CC-A2.3-15 (OutcomeSpec typing). promisedOutcomeSpecRef MUST resolve to U.OutcomeSpec (A.7:5.10). It MUST NOT be used to point at a concrete U.Work episode or at an extensional delivered object.

CC-A2.3-16 (OutcomeSpec is explicit and mode‑complete). promisedOutcomeSpecRef MUST be present and MUST reference an U.OutcomeSpec that declares mode ∈ {WorkOnly, ResultOnly, Composite} and satisfies A.7:5.10 mode completeness:

• WorkOnly → workSpec present, resultSpec absent
• ResultOnly → resultSpec present, workSpec absent
• Composite → both workSpec and resultSpec present

CC-A2.3-17 (OutcomeSpec ⇄ Work anchoring). For any U.Work that claimsPromiseContent(-, SC) (and especially for fulfilsPromiseContent(-, SC)), the Context MUST be able to derive an evidence link from that Work to SC.promisedOutcomeSpecRef:

• if SC.promisedOutcomeSpecRef.workSpec is present, the Work is compatible with methodConstraintRef (if present) and satisfies workPredicateRef;
• if SC.promisedOutcomeSpecRef.resultSpec is present, the Work’s outputs / affected referents / effect‑delta (and cited evidence carriers) satisfy postConditionRef on the referenced statePlaneRef (or its declared default plane). (You MAY materialize this as deliversPromisedOutcome(Work, OutcomeSpec) per A.2.3:8.1 for auditability.)

CC-A2.3-18 (AcceptanceSpec ⇄ OutcomeSpec binding). acceptanceSpec MUST be written as an evaluation over the same evidence base used to establish delivery of SC.promisedOutcomeSpecRef. In particular, a Work MUST NOT be judged “pass” for a promise content unless it also delivers the promised outcome spec (see fulfilsPromiseContent in A.2.3:8.1). If the Context uses multi‑grade verdicts, it MUST declare how “non‑delivery” is represented (fail, N/A, separate grade).

CC-A2.3-19 (OutcomeSpec ↔ unitOfDelivery coherence). If unitOfDelivery is present, its countingRule.selectorRef MUST select only Work episodes that are eligible to satisfy SC.promisedOutcomeSpecRef (WorkOnly / ResultOnly / Composite) and MUST define how to avoid double counting (via an explicit dedupeKeyRef or a policy cited by id) when a single Work episode can satisfy multiple clauses/bundles. The selector MAY be “all fulfilments” (fulfilsPromiseContent) but MUST NOT count non‑delivering Work episodes.

CC-A2.3-20 (Unit-of-delivery is computable from Work evidence). If unitOfDelivery is present, then it MUST declare how delivered units are computed from Work evidence (duration, quantity, cases, kWh, etc) per A.7:5.10.3. The default “1 unit per fulfilment Work” is permitted only when unitOfDelivery is a pure count of fulfilment episodes.

#Evidence relations & operators (Promise content ⇄ Work)

To keep the promise → evidence path explicit:

#Core relations

• claimsPromiseContent(Work, PromiseContent) — the Work instance intends to fulfil the promise content (pre‑verdict).
• deliversPromisedOutcome(Work, OutcomeSpec) — the Work instance evidences delivery of the promised outcome spec (work facet and/or result facet); derived from Work’s I/O/Δ plus the U.OutcomeSpec (and MAY be asserted explicitly for auditability).
• acceptanceVerdict(Work, PromiseContent) → {pass, fail, partial, context‑specific grades} — computed by applying acceptanceSpec (with its declared Γ_time and claim scope) to the same Work facts/evidence used to establish delivery.
• fulfilsPromiseContent(Work, PromiseContent) — the Work instance both (i) delivers the promised outcome spec and (ii) passes the promise content’s acceptanceSpec.
• usesAccess(Work, MethodDescription) — consumer Work that invokes the service via its accessSpec (when applicable).

Invariant: fulfilsPromiseContent(W,SC) ⇒ claimsPromiseContent(W,SC) and deliversPromisedOutcome(W, SC.promisedOutcomeSpecRef) and acceptanceVerdict(W,SC)=pass. Invariant: A Work can claim/fulfil multiple promise contents only if the context declares a counting policy (no silent double‑counting).

#Service‑clause performance operators

Let W(SC, T) be the set of Work that claimsPromiseContent(-,SC) within time window T. Let W✓(SC, T) be those with fulfilsPromiseContent.

• Delivered units: delivered(SC, T) is computed from the set W✓(SC, T) using unitOfDelivery’s countingRule (A.7:5.10). Default (when unitOfDelivery is absent): delivered(SC, T) = |W✓(SC, T)| (one unit per accepted delivery work).
• Rejection rate: rejectRate(SC, T) = 1 − |W✓(SC,T)| / |W(SC,T)| (declare handling of partial).
• Lead time: average/percentile of duration(Work) or of request→completion delta (declare definition).
• Availability/Uptime: computed from Work/telemetry events per the context’s definition (declare availability source).
• Cost‑to‑serve: sum of Γ_work over W✓ per resource category (A.15.1).

All metrics are functions of Work evidence; the promise content object is never the bearer of actuals. Aggregation across time uses Γ_time policies (union vs convex hull) chosen by the KPI owner.

#Anti‑patterns (and the right move)

• “The microservice is the service.” Rewrite to facet‑explicit terms (A.6.8): the microservice is typically a service delivery system (U.System) and/or a service access point (U.System). Keep the promise content as a promise content in U.PromiseContent, and bind accountability via U.Commitment if needed.

• “The API is the service.” The API is typically a service access spec (accessSpec : MethodDescription) (and systems playing interface roles). The promise content is the promise content judged by acceptanceSpec.

• “Our process is the service.” Process/recipe is U.Method/MethodDescription; schedule is U.WorkPlan. The promise content is what is promised to the consumer.

• “The ticket is the service.” A ticket/case is U.Work (and perhaps a WorkPlan item). Evidence and outcomes sit on Work, not on the promise content.

• “Attach cost to the service.” Actual cost/time attach to U.Work only (A.15.1). Service metrics are computed from Work.

• “Put service under BoM.” Services are not structural parts. Keep PBS/SBS clean.

• “Hard‑code people into the service.” Name role kinds in the promise content (U.PromiseContent); run‑time performers are U.RoleAssignments.

#Migration notes (quick wins)

1. Name the promises. List 5–15 consumer‑facing promises your context lives by; reify each as U.PromiseContent with acceptanceSpec and, if needed, accessSpec and unitOfDelivery.
2. Separate provider from promise content. Keep systems/teams as U.System; make them providers via …#ServiceProviderRole:Context.
3. Wire evidence. Ensure every relevant U.Work has claimsPromiseContent (and fulfilsPromiseContent post‑verdict).
4. Choose metrics. For each Service/promise content, define 2–4 KPIs and the exact Work-based formulas (availability, lead-time, rejection rate, cost-to-serve), declare the Claim scope (G) and Γ_time policy used for each KPI, and—when KPIs are numeric/comparable—define the underlying U.Characteristic + measurement procedure/evidence (C.16/C.25) and pin {UnitType, ScaleKind, ReferencePlane, EditionId}. → For each promise content, define 2–4 KPIs and the exact Work-based formulas, with explicit Γ_time.
5. Bridge domains. If a business ontology already exists (“business/technical/internal service”), keep it in its own context and map to FPF Kinds via Bridges.
6. Tidy language. Apply A.6.8 (RPR‑SERV) / L‑SERV: ban unqualified “service” as a synonym for server/team/process/ticket in normative prose; map them explicitly.

#Relations

• Builds on: A.1.1 U.BoundedContext; A.2 U.Role; A.2.1 U.RoleAssignment; A.2.2 U.Capability; A.2.6 U.Scope / U.ClaimScope (G) / U.WorkScope.
• Coordinates with: A.3.1 U.Method; A.3.2 U.MethodDescription; A.15.1 U.Work; A.15.2 U.WorkPlan; A.6.8 (RPR‑SERV) for normative prose unpacking of the service cluster; B-line Bridges & CL (CL→R; may recommend ΔG narrowing).
• Constrained by lexical rules: E.10 L‑SERV (service disambiguation); also L‑FUNC, L‑PROC, L‑SCHED, L‑ACT.
• Informs: Reporting/assurance patterns (service KPIs, SLA dashboards); catalog/exposure patterns in domain contexts.

#Didactic quick cards (engineer‑manager ready)

• Promise content = Promise content. What we advertise and are judged by.
• Method/Spec = Recipe. How we usually do it (provider‑internal).
• Work = Evidence. What actually happened and consumed resources.
• Provider/Consumer = Roles. assignment via RoleAssigning at run‑time.
• Metrics from Work. Uptime, lead time, quality are computed from Work, not from the Service object.
• Keep PBS/SBS clean. Services are not parts; they are promises.

#A.2.3:End

#U.EvidenceRole

This pattern defines how a knowledge artefact (“episteme”) serves as evidence for a specific claim or theory inside a bounded context. It is a non-behavioural role enacted via U.RoleAssignment; the evidence-role assignment must declare the target claim, the claim-scope, and a timespan of relevance. Evidence is a classificatory status of an episteme; it is not an action and it is not an assignment of an actor.

#Context and intent

FPF separates what exists (holons and their kinds) from what acts (systems under roles performing work) and from what is known (epistemes carried on symbols). Roles are contextual masks that holons may wear; role meanings are local to a U.BoundedContext. In this setting, we need a kernel‑level way to say that this episteme counts as evidence about that claim, here, and for this period, without confusing evidence with services, methods, or work.

Intent. Provide one uniform, discipline‑neutral role by which an episteme can be assigned as evidence, while keeping:

• Agency on systems performing U.Work (not on epistemes).
• Promise and Standardual language on U.PromiseContent (not on evidence).
• Recipe and eligibility on U.Method / U.MethodDescription (not on evidence).

#Problem

1. Anthropomorphising epistemes. Models say “the paper proves…”, implicitly treating a document as an actor.
2. Citation without scope. Links exist but lack explicit target claim, applicability scope, and time window.
3. Deductive versus empirical conflation. A formal derivation and a lab dataset are both called “support” although their semantics and ageing differ.
4. Staleness and drift. Empirical evidence ages; without explicit validity windows, stale evidence keeps influencing conclusions.
5. Cross‑context leakage. Evidence is interpreted as “global,” skipping the bridge that is required to move meaning across contexts.

#Forces

#Solution — Term and definition

Term. U.EvidenceRole — a non-behavioural role that a U.Episteme may play inside a U.BoundedContext to serve as evidence for a declared target claim (or theory/version). The target claim, its applicability scope, polarity, weighting model, and other normative facets are properties of the U.EvidenceRole definition itself within that bounded context.

How it is enacted. The role is enacted by a standard U.RoleAssignment that connects:

RoleAssigning {
  holder  : U.Episteme,        // the artefact: paper, proof, dataset, report…
  role    : U.EvidenceRole,    // a context-defined role with normative properties
  context : U.BoundedContext   // where the role definition is valid
  timespan?: Interval          // optional: relevance window for this specific assignment
}

The normative properties of the role (e.g., claimRef, claimScope, polarity, weightModelRef) are set in the role’s definition in the given U.BoundedContext, not in the evidence-role assignment. U.RoleAssignment carries only the linkage between a concrete episteme and a role already defined and attributed in that context.

Non-behavioural guard. The holder is an episteme; any actions that produced it are U.Work performed by systems. Evidence classifies an artefact’s evidential status; it does not itself enact behaviour.

Minimal readable grammar (informative). <Episteme>#<EvidenceRole>:<Context> — where <EvidenceRole> in <Context> already normatively specifies polarity Claim / Scope [weight].

Examples.

• In Cardio_2026, ModelFitEvidenceRole is defined with: claim = β-blocker > placebo, claimScope = adults 40–65, polarity = supports, weightModelRef = KD:SupportMeasure. Binding: Trial-R3.csv#ModelFitEvidenceRole:Cardio_2026.

• In Theory_T, AxiomaticProofRole is defined with: claim = Theorem-12, claimScope = all x ∈ D, polarity = supports. Binding: Lemma-12.proof#AxiomaticProofRole:Theory_T.

#Role family and specialisations

U.EvidenceRole is a role kind refined by specialisation (no mereology of roles). The recommended, substrate‑neutral specialisations are:

5.1 Axiomatic line (deductive inside a fixed theory)

• AxiomaticProofRole — a proof that entails a target statement in a declared U.TheoryVersion.
• CounterexampleRole — a witness that refutes a universally quantified claim in the theory.
• DerivationRole — a lemma or intermediary derivation establishing a dependency in the proof spine.
• EquiconsistencyEvidenceRole — a metaproof establishing equiconsistency or relative strength, often used to constrain theory choice.

Semantics. In a fixed theory version, these roles are boolean and non‑decaying. If the axiom base or definitions change, the binding must be re‑issued for the new version; there is no silent carry‑over.

5.2 Experimental line (empirical, inductive, and model‑selection)

• ObservationEvidenceRole — raw or processed observations under a declared method.
• MeasurementEvidenceRole — calibrated measurements with an error model and traceability.
• ModelFitEvidenceRole — comparative fit or likelihood of data to competing models; supports one over another within the declared scope.
• ReplicationEvidenceRole — independent replication status (full, partial, failed).
• CalibrationEvidenceRole — evidence about the measurement chain (instrument validity), typically constraining claims.
• BenchmarkEvidenceRole — standardised tasks or suites producing comparable scores.

Semantics. Experimental roles require a claim‑scope and a relevance timespan. Their contribution to confidence is graded and may decay; the same artefact may carry multiple bindings for different claims or scopes (distinct role assignments).

Specialisation, not stacking. Do not build chains like “transformer‑agent‑observer role.” A system enacts behavioural roles (e.g., TransformerRole) to perform work; an episteme enacts U.EvidenceRole to classify its evidential function. Keep enactment lines separate.

#Clear distinctions (Strict Distinction, litmus tests)

#Core invariants (concept level)

1. Holder type. U.EvidenceRole is held by a U.Episteme only; never by a system, work, method, or service. # [M‑0]
2. Context anchor. Every evidence-role assignment must name a U.BoundedContext; meaning is local and does not propagate implicitly.
3. Target claim. Every evidence-role assignment must reference a resolvable claim or theory statement and declare polarity {supports | refutes | constrains | neutral}.
4. Claim-scope. Every evidence-role assignment must declare an applicability scope; for the axiomatic line this can be the theory’s domain.
5. Timespan. Every evidence-role assignment must declare a relevance interval. Axiomatic roles may be open-ended for a fixed theory version; experimental roles require finite or refreshable windows. Gating: narrative only at M-0; explicit timespan & decayClass at M-2; version fence & proofChecks at F-. # [M/F]
6. Non-self-evidence. The provenance of experimental evidence-role assignments must trace to external U.Work performed by systems under roles; an episteme cannot “evidence itself.”
7. No mixing of stances. Do not mix design‑time proof artefacts and run‑time traces in one provenance chain; relate them via separate bindings if needed.
8. No role mereology. Roles have no parts; refine by specialisation only. This prevents confusing “sub‑role” with “subsystem”. Profile note: The constraint is universal (applies to all profiles). # [all]

Minimal readable grammar (informative).
<Episteme>#<EvidenceRole>:<Context> — where <EvidenceRole> is defined inside <Context> with normative facets (claimRef, claimScope, polarity, optional weightModelRef, decay policy).

Examples (illustrative only):

Cardio (empirical line)
Role definition in Cardio_2026:
ModelFitEvidenceRole with
claimRef = (β-blocker > placebo), claimScope = adults 40–65, polarity = supports, weightModelRef = KD:SupportMeasure.
Binding:
Trial-R3.csv#ModelFitEvidenceRole:Cardio_2026

Graph theory (formal line)
Role definition in GraphTheory:
AxiomaticProofRole with claimRef = Theorem-12, claimScope = all finite DAG, polarity = supports (entails), fenced to TheoryVersion = 3.1.
Binding:
Lemma-12.proof#AxiomaticProofRole:GraphTheory

#Facets and semantics (normative)

This section deepens the definition of U.EvidenceRole by specifying which normative facets are attached to its definition within a U.BoundedContext, how decay is handled, what provenance anchors are required, and how the role contributes to assurance computation.

#Claim-scope schema

Every U.EvidenceRole definition within a U.BoundedContext MUST declare a claim-scope record. This record ties the role’s meaning to the exact target claim and its claim scope, and aligns with the typed-claim form used in B.3:

#Timespan and decay

Evidence is perishable unless proven otherwise.

• Formal (axiomatic) roles MAY have open-ended timespan.to = null only if fenced to a specific U.TheoryVersion and justified in notes.
• Empirical roles MUST have a finite or refreshable timespan. Decay parameters (half-life, renewal window) are set by the context policy and referenced in the role definition.

When the relevance window closes (validUntil reached), the evidence incurs Epistemic Debt (ED). Per B.3.4, debt must trigger one of three managed actions:

1. Refresh — new work produces fresh evidence for the same claim and scope.
2. Deprecate — role is retired; claim support is reduced or removed.
3. Waive — explicit steward decision to accept the stale evidence temporarily.

#Provenance hooks

Each U.EvidenceRole MUST anchor into the Evidence–Provenance DAG (A.10):

• Formal: verifiedBy → proof artefact carrier(s), with optional checkedBy metadata for proof-checker runs.
• Empirical: validatedBy → data carriers from observed U.Work runs; protocolRef → U.MethodDescription; fromWorkSet → IDs of those runs.
• SCR/RSCR anchors (A.10) are mandatory for all carriers.

No self-evidence rule: the producing U.Work must have been performed by a system in an external role; an episteme cannot “prove itself” without independent generation.

#Contribution to assurance

A U.EvidenceRole classifies an artefact; its contribution to the target claim’s assurance tuple ⟨F, G, R⟩ is computed in B.3 using:

• F (formality) — lower-bounded by the least formal constituent in the provenance path.
• G (ClaimScope) — limited to the claim scope; unsupported regions are dropped (WLNK).
• R (reliability) — computed as:

R_eff := max(0, min_path( min_claimR(path) − Φ(CL_min(path)) ))

Here:

• min_claimR(path) is the smallest justified reliability along the path from the role to the claim in the context’s support graph.
• CL_min(path) is the lowest congruence level on that path.
• Φ is the penalty function defined by the context policy; it must be monotonic (lower CL → greater penalty).

If any element in the support chain is postulative, the aggregate epistemicMode is postulative.

TA/VA/LA distinctions:

• TA (Typing assurance) — primary effect is to improve CL on edges, reducing penalties in R computation.
• VA (Verification assurance) — primarily raises F and the logical component of R.
• LA (Validation assurance) — raises empirical R and constrains G to the validated envelope.

#Worked examples

#Formal line — Proof as evidence for a theorem

Role definition (in GraphTheory)
AxiomaticProofRole

• claimRef = Theorem-12 (“Every finite acyclic graph admits a topological ordering”),
• claimScope = all finite DAG,
• polarity = supports (entails),
• epistemicMode = formal, assuranceUse = VA,
• fenced to TheoryVersion = 3.1 (open-ended relevance as long as that version stands).

Role assignment(s)
Lemma-12.proof#AxiomaticProofRole:GraphTheory

Provenance sketch
verifiedBy → Carrier#Proof_p1 (machine-checked), usedCarrier → Carrier#Def_graph.

Effect on assurance (informative)
High F (machine-checked proof), G = “finite DAG”, R from proof-obligation integrity; potential CL penalty if an ontology bridge is used.

#Empirical line — Sensor calibration as evidence for an accuracy claim

Role definition (in Cardio_2026)
ModelFitEvidenceRole

• claimRef = “Sensor S achieves ±0.3 °C accuracy in [0,70] °C under lab conditions L”,
• claimScope = temperature [0,70] °C; humidity 30–50%; environment L,
• polarity = supports,
• epistemicMode = postulative, assuranceUse = LA,
• weightModelRef = KD:SupportMeasure, decayPolicy = annual recalibration.

Role assignment(s)
Trial-R3.csv#ModelFitEvidenceRole:Cardio_2026

Provenance sketch
validatedBy → Carrier#Dataset_calib_v5, protocolRef → MethodDescription#ThermoCalibration, fromWorkSet → {cal_run_0502, cal_run_0503}.

Effect on assurance (informative)
F from formalised procedure, G = measured envelope, R from replication and CL on unit mapping; R decays after the policy window unless refreshed.

#Conformance checklist (normative)

CC-ER-01 (Type & holder) U.EvidenceRole MUST be held by a U.Episteme via U.RoleAssignment. Systems, services, methods, or works MUST NOT hold this role.

CC-ER-02 (Context) Every evidence-role assignment MUST name a U.BoundedContext. Role meanings are local and do not propagate without an explicit bridge.

CC-ER-03 (Target claim) Every evidence-role assignment MUST reference a resolvable claimRef@version and declare polarity ∈ {supports | refutes | constrains | neutral}.

CC-ER-04 (Claim-scope) Every evidence-role assignment MUST declare claimScope. For formal proofs this may be the theory’s domain; for empirical evidence it is mandatory to state population, environment, and parameter envelope.

CC-ER-05 (Timespan) Every evidence-role assignment MUST carry a non-empty timespan. Formal line may have open-end only if fenced to a fixed theory version; empirical line must have a finite or refreshable end.

CC-ER-06 (Provenance) Every evidence-role assignment MUST anchor into the EPV-DAG (A.10). For empirical line, fromWorkSet must point to external U.Work; self-evidence is prohibited.

CC-ER-07 (Reproducibility) Empirical evidence-role assignments MUST state reproducibility ∈ {replicated-independent, replicated-internal, not-replicated, irreproducible}, with references where applicable.

CC-ER-08 (Weight discipline) If weight.score is present, weight.modelRef MUST be named and all required inputs supplied.

CC-ER-09 (Cross-context) Cross-context reuse MUST go via U.Alignment bridge; record CL_min on the path for assurance penalties.

CC-ER-10 (Version fences) If the claim or episteme versions, create a new binding; do not mutate in place.

CC-ER-11 (No role-of-role) Roles never hold roles; there is no chaining of behavioural sub-roles into non-behavioural ones.

CC-ER-12 (Terminology) Use specialisation for role refinements; reserve sub for mereology of systems or artefacts only.

CC-ER-13 (Lane declaration) Every binding SHALL declare assuranceUse ∈ {TA | VA | LA} and, for empirical (LA) bindings, expose timespan/valid_until and decayPolicy so that SCR can report lane‑separated contributions and freshness (B.3).

#Anti-patterns and remedies

#Operators (conceptual, tooling-agnostic)

These operators extend E.6.1 citation graph capabilities for evidence analysis inside a U.BoundedContext:

12.1 Per-claim evidence evidenceFor(claim, t?) → Set[EvidenceRoleAssigning] counterEvidenceFor(claim, t?) → Set[EvidenceRoleAssigning] weight(claim, t?, model?) → score # returns ordinal at M‑mode; numeric at M‑2/F‑mode. # [M/F]

12.2 Decay and windows window(claim, [t0,t1]) — filter evidence-role assignments by timespan. decayedWeight(assignment, t) — apply context decay policy.

12.3 Replication and provenance replicationLedger(binding) → Ledger isIndependentReplication(binding) → boolean

12.4 Formal line hooks proofChecks(binding) → {assistant, status, hash, kind∈{classical, constructive}} # [F‑*] dependsOnAxioms(binding) → Set[AxiomId]

12.5 Empirical line hooks fromWorkSet(binding) → Set[WorkId] protocol(binding) → MethodDescriptionId

#Relations

Builds on: A.2 U.Role, A.2.1 U.RoleAssignment (role as mask, binding as assignment), A.10 Evidence Graph Referring (EPV-DAG), B.3 Trust & Assurance Calculus.

Coordinates with: A.3.2 U.MethodDescription (protocols, proof obligations), E.6.1 Epistemic Roles via U.RoleAssignment (didactic gateway).

Informs: KD-CAL (knowledge dynamics, assurance cases), Norm-CAL (policy claims with evidence), planned U.PromiseFulfillmentEvaluation (services judged from work and reported as epistemes with evidence bindings).

#Migration notes (quick wins)

1. Enumerate claims: For each evidence collection, identify claims and create explicit bindings with polarity.
2. Separate work from reports: Facts stay on U.Work; create report epistemes to link as evidence.
3. Name the calculus: Replace free-form confidence with context-declared weight model and required inputs.
4. Fence by version/time: Bindings carry timespan and version fences; add decay class if applicable.
5. Bridge explicitly: Cross-context evidence goes through U.Alignment, not by fiat.

#Didactic quick cards (engineer-manager ready)

These are short reminders for non-specialist readers to apply U.EvidenceRole correctly:

• Evidence ≠ Work — Work is what happened; Evidence is a documented argument (episteme) about a claim in a context.
• Local, not global — Evidence links in a room (context). Outside that room, you need a bridge (U.Alignment).
• Two lines of trust — Formal line: proof artefacts checked in a declared theory version. Empirical line: observations from Work under a declared method. Both are epistemes wearing U.EvidenceRole.
• Services are promises; Work proves — KPIs are measured from Work; service evaluations can be bound as evidence for policy claims.
• Specialise, don’t stack — Use specialisations of U.EvidenceRole to refine meaning; never chain behavioural roles into evidence.

#SCR/RSCR audit stubs (assurance scaffolding)

These stubs allow concept-level validation of evidence-role assignments, without implying any specific tooling.

SCR-A2.4-E1 (Assignment integrity) Assert: holder is U.Episteme; context present; claimRef resolves; timespan non-empty; provenance anchored to EPV.

SCR-A2.4-E2 (Weight discipline) Assert: if weight.score present → weight.modelRef present and all required inputs provided; recompute to check.

SCR-A2.4-E3 (Traceability) For empirical evidence-role assignments: assignment → fromWorkSet → each U.Work has performer U.RoleAssignment and timestamps; no missing hops.

RSCR-A2.4-R1 (Regression on version bump) When claimRef or holder episteme versions change, ensure new bindings are created; no in-place mutation.

RSCR-A2.4-R2 (Decay check) Bindings past timespan.to or with expired decayClass are flagged for review per context policy.

#Minimal evidence-role assignment schema (informative)

EvidenceRoleAssigning:
  id: ERB-…
  context: <BoundedContextId>
  holder: <EpistemeId>                # paper/proof/dataset/report
  role: <EvidenceRoleId>              # defined within the context, with normative properties
  timespan?: {from: ISO-8601, to: ISO-8601|null} # optional assignment window
  provenance:
    formal?: { theoryRef: <TheoryId>, proofArtifactRef: <CarrierId>, checkedBy?: <ProofCheckId> }
    empirical?: { protocolRef: <MethodDescriptionId>, fromWorkSet: [<WorkId>… ], dataCarrierRef?: <CarrierId> }

#Memory hooks and acceptance cross-checks (informative)

Memory hook: “Evidence links a document to a claim in a Context, for a time, with a trail.” (document = episteme; claim = scoped thesis; Context = bounded context; time = timespan/decay; trail = provenance)

Acceptance cross-checks before publishing a binding:

1. Holder: Is it a U.Episteme?
2. Context: Is the U.BoundedContext declared?
3. Claim: Does claimRef resolve? Is polarity set?
4. Scope: Is claimScope complete? For empirical, are population/env/parameters given?
5. Timespan: Is it finite or fenced (formal line)?
6. Provenance: Is EPV anchored? Any self-evidence?
7. Reproducibility: For empirical, is it declared?
8. Weight: If scored, is the model named and inputs complete?
9. Cross-context: If imported, is U.Alignment bridge in place with CL_min recorded?
10. No role-of-role: Is this role bound directly to an episteme without chaining behavioural roles?

#A.2.4:End

#U.RoleStateGraph: The Named State Space of a Role

#Purpose & scope (why this exists)

A role is not only a name; it is a trajectory of admissible states that governs when, and under which conditions, a holder of that role may enact steps of a U.MethodDescription. FPF therefore introduces a first‑class intensional object:

U.RoleStateGraph (RSG) — the finite, named state space of a U.Role in a given U.BoundedContext, with transitions guarded by conditions over the Role Characterisation Space (RCS) and contextual events.

The RSG is the gate between assignment (U.RoleAssignment) and action (U.Work). A step may be performed only when the performer’s assignment is in an enactable RSG state at the relevant Window (time slice) and this is proven by a contemporaneous StateAssertion (verdict of U.Evaluation against the state’s Checklist).

#Problem frame (what goes wrong without an RSG)

1. Readiness blur. Teams conflate “has the badge” with “is fit to act now”. Without explicit states (Ready, Calibrated, Authorized, Suspended…), enactment checks dissolve into ad‑hoc judgement.
2. Checklist drift. Criteria for “ready/approved” live in scattered documents; there is no single conceptual anchor tying them to the role.
3. Workflow/role confusion. “State” of a workflow (according to workplan) is mistaken for the state of a role (eligibility to enact).
4. Status ≠ enactment. Epistemic/Normative roles (e.g., NormativeStandard, ApprovedSpecification) need statuses that are not enactable, yet are used to gate decisions.
5. Cross‑context substitution by name. Labels like Approved or Ready silently cross contexts with different criteria; the loss is hidden and unaudited.

Consequences. Violations of Strict Distinction (A.7) and Didactic Primacy (E.12): ambiguous authority to act, unsafe SoD, and non‑reproducible evaluations.

#Core idea (didactic)

Think of a Role as a mask, and the RSG as the traffic lights for that mask inside one context of meaning.

• The nodes are named states (Ready, Degraded, Suspended, Approved, Obsolete…).
• The edges are transitions with guards (checkable conditions over RCS characteristics and contextual events, e.g., CalibrationAge ≤ 30d; AuthorizationSpeechAct recorded).
• Each state is paired with a Checklist (criteria you test to issue a StateAssertion for a given Window).
• Some states are enactable = true (green lights); others are not enactable (status lights) and therefore can gate decisions but cannot directly authorize U.Work.

One sentence. RSG says when a badge is green. The Checklist proves it, the StateAssertion records it, and the Method step may proceed.

#Minimal vocabulary (this pattern only)

• U.RoleStateGraph (RSG). Intensional object owned by (Role, Context). Finite set of named States and typed Transitions with guards.

• RSG.State. Intensional named place. Properties:

  • enactable ∈ {true,false} — whether being in this state authorizes enactment of steps that require this role.
  • initial?, terminal? — optional markers for lifecycle reasoning.

• RSG.Transition. Edge state_i → state_j with Guard (predicate over RCS characteristics and/or contextual events such as U.SpeechAct, U.Observation, U.Evaluation results).

• RCS (Role Characterisation Space). The characteristic bundle that characterises this role in this Context (e.g., CalibrationAge, AuthorizationScope, FatigueIndex, IndependenceFlag, EvidenceFreshness). (Defined in A.2 Role Taxonomy / RoleDescription.)

• State Checklist (description). A RoleDescription component that enumerates criteria to test whether a holder can legitimately be treated as in a given state for a Window. (Description, not the state itself.)

• U.Evaluation → StateAssertion (verdict). The result of applying the state’s Checklist to a concrete holder at a time window, yielding a verdict “IN‑STATE(S) @Window” with provenance to observations/evidence.

• Window. Temporal interval to which the StateAssertion applies (e.g., [2025‑05‑01, 2025‑06‑01]).

Strict distinction note.

• RSG and its States are intensionals (what the role is allowed to be).
• Checklists and StateAssertions are descriptions/evaluations (how we know a specific holder is in that state now).

#What an RSG is not (guardrails)

• Not a workflow. RSG transitions do not encode task order; they encode eligibility changes of the role.
• Not a capability list. RSG is authorization/readiness over time, distinct from U.Capability (ability).
• Not a global status set. RSG lives inside one Context; the label Ready in another Context is a different state unless bridged (F.9).
• Not a log. RSG is not a history. Histories are StateAssertions over Windows; U.Work is the record of enactments.
• Not a document lifecycle. Epistemic role RSGs can look like document lifecycles, but they remain role‑status graphs; the carrier lifecycle stays separate (A.7, U.Carrier).

#Invariants (preview)

1. Locality. RSG(Role, Context) is defined only within that U.BoundedContext.
2. Finiteness. The State set is finite and named.
3. Checklist pairing. Every State has a Checklist in the Role’s RoleDescription; every enactable State has at least one observable criterion.
4. Green‑gate discipline. A Method step requiring Role may proceed only if a contemporaneous StateAssertion exists for an enactable State.
5. No silent Cross‑context reuse. Cross‑Context reuse requires a Bridge with CL and loss notes; local ⊥/≤/⊗ always prevail.

#Formal structure of an RSG (intensional, context‑local)

Definition. For a given U.Role in a given U.BoundedContext, its U.RoleStateGraph is the tuple RSG(Role, Context) = ⟨S, S_en, T, Guard, init?⟩, where:

• S — a finite set of named States (StateName ∈ Tech register, with a Plain label). Names are local to (Role, Context).

• S_en ⊆ S — the subset of enactable states (“green lights”). States in S \ S_en are status‑only (not enactable).

• T ⊆ S × S — a set of typed transitions sᵢ → sⱼ. Transitions are optional; the RSG may be acyclic or cyclic.

• Guard — for each transition (and optionally for state maintenance), a predicate over:

  • the role’s RCS snapshot at a Window (values on named characteristics; see A.2.3), and
  • Context events (e.g., presence of a U.SpeechAct, freshness of U.Observation, validity of a prior U.Evaluation).

• init? : S → {true,false} — optionally marks initial state(s). (Useful for lifecycles; not required for gating.)

Naming discipline (RSG‑N1…N3).

1. RSG‑N1 (Minimal set). |S| ≥ 1. At least one state must exist; if no state is enactable, the role is status‑only in this Context.
2. RSG‑N2 (Disjoint labels). State names are unique within (Role, Context); reusing global labels (e.g., “Ready”) across contexts is allowed only via Bridges (F.9).
3. RSG‑N3 (Human scale). For didactics, ≤ 7 states is the default target; exceeding it requires a one‑sentence rationale (“distinct gate we will actually use”).

#Enactability & Checklist semantics (how a state is known, now)

An RSG does not determine history; it determines what counts as being in a state, and which states authorize enactment.

#State Checklists (description, not the state)

For each s ∈ S, the RoleDescription (A.2.3) includes a State Checklist Checklist(s) — a named set of criteria that can be evaluated at a Window to test “holder is in state s”.

• Criterion kinds (illustrative):

  • Threshold over RCS characteristic: CalibrationAge ≤ 30 days.
  • Presence of act: AuthorizationSpeechAct exists within 90 days.
  • Evidence freshness: Evidence(type=SafetyTest).age ≤ 12 months.
  • SoD flag: IndependenceFlag = true.
  • External status: StandardStatus = Approved.

Strict distinction. Checklist(s) is a description; the state s is an intensional place in the role’s RSG.

#From Checklist to StateAssertion (verdict of U.Evaluation)

Evaluating Checklist(s) at a Window produces an U.Evaluation verdict:

StateAssertion(holder, Role, Context, s, Window) — “For this Window, this holder is in state s”, with provenance to the actual observations/evidence.

Rules (RSG‑C1…C5).

• RSG‑C1 (All‑must‑hold). A StateAssertion MUST justify that all required criteria in Checklist(s) hold at the Window.
• RSG‑C2 (Window freshness). Each criterion MUST define its freshness window; if omitted, default is instantaneous at the Window’s end time.
• RSG‑C3 (No guess). Pure opinion is disallowed; every criterion is grounded in observable facts (U.Observation, U.Work record, U.SpeechAct, or a derived U.Evaluation).
• RSG‑C4 (Non‑monotonic over time). A StateAssertion is not permanent; once the Window ends, a new evaluation is needed unless a maintenance guard keeps it valid (see 8.3).
• RSG‑C5 (Uniqueness not required). Multiple states may be asserted for the same Window if their criteria do not conflict (e.g., Ready and Authorized). Enactability is governed by §8.4.

#Transitions & guards (admission, maintenance, exit)

RSG transitions express how eligibility changes when guards fire. Guards are predicates; the RSG stays notation‑neutral.

• Admission guard (→ s) declares conditions to enter state s.
• Maintenance guard (s ↺) must hold to remain in s (e.g., FatigueIndex < 0.8, checked every shift).
• Exit guard (s →) declares conditions to leave s (e.g., CalibrationAge > 30d).

Rules (RSG‑G1…G3).

• RSG‑G1 (Checklists vs guards). Checklists decide recognition (“am I in s now?”). Guards describe change (“what moves me in/out of s?”). They may reuse the same predicates; their roles are distinct.
• RSG‑G2 (No control‑flow). Guards may refer to events (e.g., “Calibration completed”), but RSG is not a task graph; it does not prescribe task order.
• RSG‑G3 (Observable basis). Every guard references observable RCS characteristics or recorded events (no hidden timers).

#The Green‑Gate Law (enactment gating)

Law (RSG‑E1). A U.MethodDescription step that requires role R may be enacted at Window W iff there exists a StateAssertion(holder, R, Context, s, W) with s ∈ S_en.

Corollaries:

• RSG‑E2 (Specialization lift). If the step requires a general role R, and the holder has a StateAssertion for a specialist role R' ≤ R in an enactable state whose lift (see §9.1) is enactable for R, the gate passes.
• RSG‑E3 (Bundle gate). If the step requires a bundle R* = R₁ ⊗ … ⊗ Rₙ, enactment requires n distinct StateAssertions meeting RSG‑E1 for each Rᵢ (unless the Context defines a CompositeRole with its own RSG; see §9.3).
• RSG‑E4 (Status‑only roles). Roles with S_en = ∅ can never authorize enactment; they may gate decisions (e.g., ApprovedSpecRole) but not U.Work.

#Interaction with role algebra (≤, ⊥, ⊗) and refinement

#Specialization (≤) — RSG refinement map

When R' ≤ R (Specialist role refines General role) in the same Context, their RSGs must align by a refinement map.

Rule (RSG‑R1 Refinement). There exists a surjective mapping π : S(R') → S(R) such that:

1. Enactability preservation: s' ∈ S_en(R') ⇒ π(s') ∈ S_en(R).
2. Checklist entailment: Checklist_R'(s') ⇒ Checklist_R(π(s')) (each specialist state’s criteria imply the general state’s criteria).
3. Guard monotonicity (informal): Transitions in R' do not weaken the general readiness implied by R (entering/exiting patterns respect π).

Interpretation. Being in s' for R' guarantees being in π(s') for R. Thus StateAssertions lift along π, enabling RSG‑E2.

Design note. RCS for R' may extend that of R; specialist states can be stricter (more criteria) but not looser than their general counterparts.

#Incompatibility (⊥) — state‑aware SoD

R_A ⊥ R_B (within the same Context) states that a single holder must not have overlapping, enactable authority for both roles.

Rule (RSG‑I1). At Window W, a holder violates R_A ⊥ R_B iff there exist StateAssertions … in s_A ∈ S_en(R_A) and … in s_B ∈ S_en(R_B) both valid at W.

Optional refinement (soft ⊥). Contexts may tighten incompatibility by listing state pairs that are forbidden (e.g., Ready_A ⊥ Authorized_B), while allowing benign combinations (e.g., Suspended_A + Ready_B). By default, any enactable pair conflicts.

Didactic payoff. SoD is checked by states in Windows, not by static role labels.

#Bundles (⊗) — conjunction without product explosion

A bundle role R* := R₁ ⊗ … ⊗ Rₙ expresses “must wear all these badges at once”.

Rule (RSG‑B1). If R* exists only as a requirement macro, do not construct a product RSG. The gate for a step requiring R* is satisfied by n separate StateAssertions sᵢ ∈ S_en(Rᵢ) at the same Window.

Rule (RSG‑B2 CompositeRole). If the Context declares R* as a first‑class U.Role, it MUST also specify an RSG(R*) and an embedding ιᵢ : S(R*) → S(Rᵢ) that preserves enactability; being in an enactable state of R* implies being enactable in each Rᵢ.

Rationale. Avoid combinatorial blow‑up by default; allow a composite role only when the organization genuinely maintains its own readiness graph.

#Readiness monotonicity across specialization & bundles

• RSG‑M1 (Specialist suffices). If a step requires R, any R' ≤ R whose lifted state is enactable suffices.
• RSG‑M2 (Bundle conjunctivity). If a step requires R₁ ⊗ R₂, the performer must produce both gates (two StateAssertions), unless a CompositeRole with RSG exists and is used.

#Guard design (types and discipline)

To keep RSGs operational but not procedural, guards draw on observable inputs only.

Guard types (non‑exhaustive).

1. Threshold guards over RCS characteristics FatigueIndex < 0.8, CalibrationAge ≤ 30d, EvidenceFreshness(role=Tester) ≤ 90d.
2. Event guards (occurrence since last Window) exists SpeechAct(type=Authorization), exists Evaluation(verdict=Pass, checklist=SafetyKit).
3. Temporal guards (time within range) now ∈ AuthorizationValidityWindow, MaintenanceWindow not active.
4. Relational guards IndependenceFrom(holder=X) = true (for SoD), NoOpenIncident(severity≥High).

Rules (RSG‑G4…G6).

• RSG‑G4 (Observable only). Each guard MUST be checkable from observable artefacts (observations, work logs, speech acts, evaluations) or present RCS values.
• RSG‑G5 (Context‑local semantics). Guard semantics are scoped to Context; Cross‑context reuse requires a Bridge (§14 in Part 1/4, F.9).
• RSG‑G6 (Didactic sparseness). Prefer few, stable guards over many brittle micro‑conditions. If a guard encodes task order, you are drifting into workflow; refactor back to eligibility.

Allowed guard evidences include:

• Observation facts (measurements/metrics),
• Evaluation verdicts (checklist results),
• SpeechAct occurrences (communicative U.Work), identified by role, act kind, and window (e.g., “Approved(change=4711)”).

A SpeechAct can change the state (e.g., Prepared→Authorized) but does not by itself satisfy operational steps; it only opens their Green‑Gate.

#Putting it together (one‑screen mental model)

At any Window:

1. RoleAssignment exists (A.2.1): Holder#Role:Context.
2. StateAssertion(s) exist: the holder is in one or more states as proven by checklists (U.Evaluation).
3. Green‑Gate Law applies: if at least one asserted state is enactable, role‑gated Method steps may be enacted; if all are status‑only, the role can gate decisions but not perform work.
4. Role algebra checks: specialization lifts readiness; bundles require conjunction; incompatibilities are detected when two enactable states coincide for the same holder at the same Window.

This yields a clean separation:

• assignment (RoleAssignment)
• Readiness (RSG + Checklists + StateAssertions)
• Action (U.Work, gated by RSG)

…and keeps meaning local, evidence observable, and reasoning testable.

#Archetypal RoleStateGraphs (cross‑domain patterns)

Below are didactic, reusable RSG skeletons for the three principal behavioural role families and for epistemic/status roles. Names and criteria are context‑local; treat them as templates to specialise inside your U.BoundedContext (E.10.D1). For each RSG we list:

• S — candidate States (enactable states marked [E]);
• Checklist gist — the recognition criteria (cf. §8.1);
• Guards — illustrative admission/maintenance/exit predicates (cf. §8.3).

Reminder. Only enactable states (S_en) can open the Green‑Gate for U.Work (RSG‑E1). Status‑only states gate decisions but never execution.

#AgentialRole (decision‑capable actor)

Context sketch: Ops_ChangeManagement_2025. RCS (characteristics, examples): CompetenceLevel, FatigueIndex, IndependenceFlag, AuthorizationValidity, IncidentLoad, RiskClass.

States S

• Unprepared — training incomplete; checklists fail.
• Prepared — training + competence thresholds met.
• Authorized — valid approval window present. [E]
• Ready — Prepared ∧ Authorized ∧ FatigueIndex < τ. [E]
• Active — contemporaneous U.Work step is underway under this role (with a valid StateAssertion in the window). [E]
• Suspended — temporary block (incident/conflict).
• Revoked — authorization expired/withdrawn.

Checklist gist

• Prepared: certificates valid; recency of practice ≤ X; simulator score ≥ Y.
• Authorized: exists SpeechAct(type=Approval, scope=Role, age≤30d).
• Ready: Prepared ∧ Authorized ∧ independence from conflicting work; fatigue within limits.

Guards

• Admission → Prepared: ExamPassed ∧ SimulatorScore≥Y.
• Admission → Authorized: presence of approval speech‑act within window.
• Maintenance Ready ↺: FatigueIndex<τ ∧ IncidentLoad≤k.
• Exit Ready → Suspended: high‑severity incident assigned OR SoD violation detected.
• Exit Authorized → Revoked: window elapsed or explicit revoke speech‑act.

#TransformerRole (non‑agential executor of change)

Context sketch: PlantOps_Pipeline_2025. RCS: CalibrationAge, SafetyInterlock, SelfTestPass, EnvRangeOK, DegradationIndex.

States S

• Unavailable — offline, missing prerequisites.
• Calibrated — calibration fresh; self‑test ok.
• Permitted — safety interlocks clear; clearance token valid.
• Ready — Calibrated ∧ Permitted ∧ EnvRangeOK. [E]
• Running — executing a method step (with contemporaneous StateAssertion). [E]
• Degraded — still operable under derated envelope. [E] (if policy allows)
• Quarantined — suspected hazard; no enactment.

Checklist gist

• Calibrated: CalibrationAge≤30d ∧ SelfTestPass=true.
• Permitted: SafetyInterlock = Clear ∧ NoOpenIncident(sev≥High).
• Ready: Calibrated ∧ Permitted ∧ environment in spec.

Guards

• Admission → Calibrated: calibration record timestamp ≤30d.
• Maintenance Ready ↺: env sensors within limits; no new hazard event.
• Exit Ready → Quarantined: detected leak OR hazard alarm.
• Transition Running → Ready: step completed ∧ cool‑down satisfied.
• Transition Ready → Degraded: DegradationIndex∈[d₁,d₂] ∧ derate policy active.

#ObserverRole (measurement actor, incl. SOSA/SSN style)

Context sketch: Lab_Thermo_2025. RCS: CalibrationAge, TraceabilityChainOK, DriftRate, SyncError, CleanlinessScore.

States S

• Unqualified — no metrological chain.
• Calibrated — with traceability to standard.
• Synchronized — time/phase sync within tolerance.
• In‑Range — drift & environment within spec.
• Measuring — performing observation. [E]
• Stale — calibration or sync expired.
• Quarantined — suspect bias/contamination.

Checklist gist

• Calibrated: traceability cert valid; calibration within period.
• Synchronized: SyncError≤ε.
• In‑Range: drift ≤ threshold; contamination tests passed.
• Measuring: Calibrated ∧ Synchronized ∧ In‑Range AND observation procedure active.

Guards

• Admission → Calibrated: calibration event recorded < 180d.
• Exit Calibrated → Stale: calibration age > threshold.
• Exit In‑Range → Quarantined: contamination alert OR failed control sample.
• Transition Measuring → In‑Range: procedure complete.

Note. Many ObserverRole states are pre‑enactment gates; only Measuring is enactable.

#Epistemic/status roles (no enactment)

These roles are status‑only; S_en = ∅. They gate decisions (e.g., can be cited, can constrain), but can never authorize U.Work.

#NormativeStandardRole

States: Draft, Candidate, Approved, Superseded, Deprecated. Checklist gist: governance decision records; publication identifiers; supersession links. Guards: Approved → Superseded on adoption of newer edition; Candidate → Approved after ratification vote.

#EvidenceRole

States: Collected, Verified, Validated, Obsolete, Contested. Checklist gist: verification/validation U.Evaluation present; freshness window; reproducibility tag. Guards: decay to Obsolete by age; transition to Contested upon counter‑evidence.

#RequirementRole

States: Proposed, Accepted, Implemented, Verified, Waived. Checklist gist: acceptance decision; trace links to U.Work; verification report; waiver authorization. Guards: Accepted → Implemented when linked executions close; Implemented → Verified on passed acceptance checklist; Any → Waived by authorized speech‑act.

#One‑screen authoring templates (didactic cards)

Keep each RSG teachable on one screen. Use the following notation‑neutral templates when drafting RoleDescriptions (A.2.3).

#RSG card (per Role, per Context)

RSG for: <RoleName>   Context: <ContextName/Edition>
RCS characteristics (gist): <characteristic1>, <characteristic2>, … 
States (◉ = enactable):
  - [◉] <StateName> — checklist gist; typical admission/maintenance/exit
  - [  ] <StateName> — … 
  - … 
Green‑Gate: step requiring <RoleName> is enactable iff holder asserts any ◉ state at Window.
Role algebra hooks: specialization (≤ … ), incompatibility (⊥ … ), bundles (⊗ … ).

#State checklist snippet (per State)

State <StateName> (enactable? yes/no)
Checklist (all must hold at Window):
  - <Observable criterion 1>  (e.g., CalibrationAge ≤ 30d)
  - <Observable criterion 2>  (e.g., exists SpeechAct(Approval) age ≤ 30d)
Maintenance (optional): <predicate> (e.g., EnvRangeOK)
Evidence Graph Ref: <Observation/Evaluation ids>

#Specialization refinement map (R' ≤ R)

Refinement map π : S(R') → S(R)
R' state        π(state in R)   entailment note (why Checklist_R' ⇒ Checklist_R)
-----------     -------------    -----------------------------------------------
<Ready+>        Ready            adds stricter fatigue & independence thresholds
<Authorized+>   Authorized       requires same approval + extra duty segregation
… 

#SoD focus (⊥) — enactable pairs

Incompatibility ⊥ (applies when both sides enactable at same Window):
  <RoleA.StateX>  ⊥  <RoleB.StateY>
  <RoleA.(any ◉)> ⊥  <RoleB.(any ◉)>   // default if not refined
Rationale: <one‑line reason>

Didactic cue. If your “template” spills beyond a screen, you’re drifting into workflow. Pull back to eligibility (RSG) and recognition (checklists).

#Cross‑context adjustments (via Bridges, not imports)

RSGs are context‑local. When similar roles appear in different Contexts, relate them with an Alignment Bridge (F.9), never by silently importing state names.

#State name correspondence (lossy mapping)

Bridge example: Observer readiness across two contexts:

Bridge: Observer-RSG alignment
From: Lab_Thermo_2025.ObserverRole
To:   Metrology_Line_2025.ObserverRole
Map (with CL):
  Calibrated(Lab)     ≈  Calibrated(Metro)            CL=3 (minor criterion diffs)
  In‑Range(Lab)       ↘  Fit‑for‑Use(Metro)           CL=2 (Metro adds robustness test)
  Measuring(Lab)      ↔  Measuring(Metro)             CL=3
Notes: 'Synchronized' in Lab maps to 'Time‑Aligned' in Metro (terminology shift).
Losses: Metro’s 'Robustness' has no direct Lab counterpart (explicit loss recorded).

Rule (RSG‑X1). A Bridge MUST record losses and extra criteria; it MUST NOT assert identity without a stated CL (congruence level).

#Authorization vocabulary drift (deontic vs operational)

Bridge note: In some IT change contexts, “Authorized” (deontic) overlaps with “Permitted” (operational). A Bridge can explain the design choice:

• Authorized(AgentialRole@ITIL) ↔ Permitted(TransformerRole@IEC) with CL=1 and a note: operational interlock ≠ managerial approval; both required to lift to Ready under our policy.

Payoff. Bridges keep local honesty while enabling Cross‑context reasoning with explicit penalties (B.3).

#Author conformance (write good RSGs)

When you define or revise an RSG, check these concept‑level rules. They are easy to hold in mind; no tooling implied.

CC‑RSG‑01 (Locality). State names and meanings are scoped to (Role, Context). Reuse across contexts only via a Bridge (F.9).

CC‑RSG‑02 (Enactability). Mark which states are enactable (S_en). If none are, the role is status‑only (valid); then it cannot open the Green‑Gate.

CC‑RSG‑03 (Observable criteria). Every checklist item must be observable (Observation, Work record, SpeechAct, or derived Evaluation). No opinions.

CC‑RSG‑04 (Guard discipline). Guards gate change, checklists recognise state. Don’t smuggle task order into guards; workflow lives elsewhere (A.15).

CC‑RSG‑05 (Refinement map). If you declare R' ≤ R, provide a π‑map and ensure entailment (RSG‑R1). Specialist states may be stricter, never weaker.

CC‑RSG‑06 (SoD by state). Define ⊥ in terms of enactable pairs. Avoid blanket ⊥ if finer, state‑aware rules reduce false conflicts.

CC‑RSG‑07 (Human scale). Default to ≤ 7 states. If you exceed, add a one‑sentence didactic rationale (“distinct gate we will actually use”).

CC‑RSG‑08 (Green‑Gate wiring). Ensure every MethodDescription step that requires this Role names the ◉ states it expects, or relies on the default “any ◉”.

CC‑RSG‑09 (Window clarity). Checklists specify freshness windows; state assertions are Window‑bound and non‑permanent.

CC‑RSG‑10 (Status/behaviour split). Epistemic/status roles: S_en = ∅. They gate decisions, not Work. Behavioural roles require U.System holders (A.2.1).

#Extended grounding across four disciplines

Each vignette shows (i) the Context, Role, RCS characteristics, States (◉ = enactable), Green‑Gate condition, and how a U.Work is gated by a U.RoleAssignment+RSG. Names are context‑local.

#Clinical surgery (medicine)

Context. Hospital.OR_2026 Role. SurgeonRole (AgentialRole) RCS characteristics. CompetenceLevel, FatigueIndex, AuthorizationValidity, CaseComplexityBand, TeamSoD.

States.

• Unprepared — training/recency incomplete.
• Prepared — credentials valid; recency ≤ 90 days.
• Authorized — procedure‑specific approval active.
• Ready — Prepared ∧ Authorized ∧ FatigueIndex<τ ∧ TeamSoD_OK. ◉
• Operating — currently performing steps. ◉
• Suspended — incident or conflict raised.
• Revoked — approval expired/withdrawn.

Green‑Gate. A MethodDescription step tagged requires: SurgeonRole is enactable iff the performer’s RoleAssignment asserts Ready at the Window.

Work gating. performedBy = Dr.Kim#SurgeonRole:Hospital.OR_2026 is valid for step “Incision” only when Ready(Dr.Kim, SurgeonRole, OR_2026, W) holds (checklist items: approval id, fatigue score, SoD against AuditorRole).

#Software operations (SRE)

Context. SRE_Prod_Cluster_EU_2026 Role. IncidentCommanderRole (AgentialRole) RCS characteristics. OnCallStatus, PageFreshness, AuthorityToken, CognitiveLoad, ConflictSoD.

States.

• Off‑Duty — not on call.
• On‑Call — rota active; page reachable.
• Authorized — escalation token valid.
• Ready — On‑Call ∧ Authorized ∧ CognitiveLoad≤k ∧ SoD_OK. ◉
• RunningIncident — commanding an active incident. ◉
• CoolingDown — post‑incident refractory period.
• Blocked — conflict with ChangeAuthorRole detected.

Green‑Gate. Steps in “Major Incident Process” that require: IncidentCommanderRole open only with Ready.

Work gating. performedBy = Dana#IncidentCommanderRole:SRE_Prod_Cluster_EU_2026 is invalid for “Declare SEV‑1” if ConflictSoD(ChangeAuthorRole) holds or PageFreshness>5 min.

#Laboratory metrology

Context. Metrology_Thermo_2026 Role. ThermometerObserverRole (ObserverRole) RCS characteristics. CalibrationAge, DriftRate, TraceabilityChainOK, CleanlinessScore, SyncError.

States.

• Unqualified — missing traceability.
• Calibrated — cert valid (≤ 180 d); drift within baseline.
• Synchronized — SyncError≤ε.
• In‑Range — contamination absent; env OK.
• Measuring — procedure active. ◉
• Stale — calibration/sync expired.
• Quarantined — suspected bias.

Green‑Gate. MethodDescription step “Record temperature” is enactable only in state Measuring (which requires Calibrated ∧ Synchronized ∧ In‑Range).

Work gating. performedBy = SensorT‑17#ThermometerObserverRole:Metrology_Thermo_2026 is rejected if CalibrationAge>180 d or ControlSampleBias>δ.

#Governance / compliance

Context. Finance_Audit_2026 Role. IndependentAuditorRole (AgentialRole) and EvidenceRole (status‑only) RCS (auditor). CertificationLevel, IndependenceFlag, AssignmentToken, CaseLoad. States (auditor). Ready/Auditing as in §12.1; ⊥ with DeveloperRole. RCS (evidence). VerificationStatus, ValidationStatus, Age, ProvenanceChainOK. States (evidence). Collected, Verified, Validated, Contested, Obsolete (status‑only).

Green‑Gate. Audit step requires: IndependentAuditorRole — enactable only with Ready and ⊥ DeveloperRole at the Window. Evidence states gate decisions (e.g., “accept finding”), never open Work.

Work gating. performedBy = Alice#IndependentAuditorRole:Finance_Audit_2026 fails if Alice holds any overlapping DeveloperRole binding in the same context.

#Acceptance harness (static conformance)

Author‑facing checks; notation‑free, concept‑level. Use them when drafting or reviewing an RSG.

SCR‑A.2.5‑S01 - Local scope. Every state name is qualified by (Role, Context). No global states. SCR‑A.2.5‑S02 - Enactability mark. The set S_en is explicit; each ◉ state is listed. SCR‑A.2.5‑S03 - Observable checklists. Each state has a Checklist of observable predicates (Observation / Evaluation / SpeechAct / Work evidence). SCR‑A.2.5‑S04 - Green‑Gate wiring. Every MethodDescription step that names the Role either (a) names its ◉ state(s) or (b) relies on the default “any ◉” policy; the RSG declares which. SCR‑A.2.5‑S05 - Guard discipline. Guards only gate transitions; they do not encode task order. SCR‑A.2.5‑S06 - SoD by state. Incompatibilities (⊥) are declared over states (or “any ◉”), not over bare role names. SCR‑A.2.5‑S07 - Specialisation entailment. For every R' ≤ R, a refinement map π: S(R')→S(R) is provided; each mapped pair has an entailment note (why Checklist_R' ⇒ Checklist_R). SCR‑A.2.5‑S08 - Human scale. |S| ≤ 7 unless a one‑line didactic rationale is recorded. SCR‑A.2.5‑S09 - Status‑only roles. If S_en=∅, the Role is explicitly tagged status‑only; it cannot open the Green‑Gate. SCR‑A.2.5‑S10 - Bridge discipline. Any cross‑context reuse is via an Alignment Bridge (F.9) with recorded CL and losses; no silent imports.

#Regression harness (evolution checks)

Use when adding/removing states, changing criteria, or bridging across contexts.

RSCR‑A.2.5‑R01 - State churn impact. For every added/removed/renamed state, list affected MethodDescription steps and Work validators; confirm the Green‑Gate policy remains decidable. RSCR‑A.2.5‑R02 - Entailment stability. When R' ≤ R changes, update the π map and re‑justify entailments; fail the check if any previously valid entailment breaks. RSCR‑A.2.5‑R03 - SoD coverage. After edits, recompute the set of enactable pairs; verify declared ⊥ still blocks all intended conflicts and no longer blocks permitted cases. RSCR‑A.2.5‑R04 - Evidence freshness. If any checklist predicate uses age/freshness, ensure default Windows are documented and existing state assertions re‑evaluate accordingly. RSCR‑A.2.5‑R05 - Bridge congruence drift. If a Bridge maps states with CL=k, and either side’s checklist changes, revisit the mapping; do not keep CL unchanged by default—raise or lower with a short rationale. RSCR‑A.2.5‑R06 - Status/behaviour split. Verify behavioural roles still require U.System holders (A.2.1); status‑only roles still have S_en=∅. RSCR‑A.2.5‑R07 - One‑screen rule. If cumulative edits push the RSG beyond one screen, split states or tighten criteria; record a one‑line teaching rationale if you must exceed.

#Common failure modes (and quick remedies)

#Didactic script (90 seconds): how A.2.5 ties to A.2.1 & A.2.3

*“A role assignment says who wears which mask where (A.2.1). The RoleStateGraph says when that mask is actually wearable. Each role’s RSG is a small named state space with checklists for each state. Some states are enactable (◉): they open the Green‑Gate for Work. Others are status‑only: they gate decisions, never execution.

A RoleDescription (A.2.3) is where you publish the role’s RCS (characteristics), its RSG (states + checklists + guards), and any role algebra (≤, ⊥, ⊗) specific to your context.

In practice: a MethodDescription step lists required roles; at runtime, a Work record is valid only if its performer is a RoleAssignment whose RSG asserts an enactable state at the Window. That’s the Green‑Gate.

Different Contexts may use the same role labels. We never assume global meaning; we relate Contexts with Bridges that map states and record losses.

Keep each RSG on one screen, with observable checklists. If you’re writing task order, you’ve slipped into workflow—move it to the Method. If you’re writing opinions, convert them into observables or drop them. That’s the whole trick.”*

#Relations (quick pointers)

• Builds on: A.2.1 U.RoleAssignment (the binding that can assert states); A.2.3 U.RoleDescription (the carrier of RSG); E.10.D1 (Context discipline).
• Enables. A.15 (Role‑Method‑Work Alignment via Green‑Gate); B.3 (Trust penalties when crossing Bridges with lower CL).
• Interacts with. D‑cluster deontics (speech‑acts gate Authorized‑like states for agential roles); F.9 (state‑level alignment across contexts).

#A.2.5:End

#Unified Scope Mechanism (USM): Context Slices & Scopes

One-line summary. Introduces a single, context-local scope mechanism for all holons: U.ContextSlice (where we reason and measure) and a family of set-valued scope types (USM scope objects, U.Scope), specialized as U.ClaimScope for epistemes (G in F–G–R), U.WorkScope for system capabilities, and U.PublicationScope for publication carriers; with one algebra (∩ / SpanUnion / translate / widen / narrow / refit) and uniform Cross-context handling (Bridge + CL).

Replaces / deprecates. This pattern supersedes the scattered use of labels applicability, envelope, generality, universality and capability envelope where they tried to stand in for the one scope mechanism. From now on:

• For epistemes, the only scope type is U.ClaimScope (nick G in F–G–R).
• For system capabilities, the only scope type is U.WorkScope.
• For publication carriers (views/cards/lanes), the only scope type is U.PublicationScope.
• The abstract architectural notion is U.Scope — a set-valued USM object over ContextSliceSet with its own algebra (∩ / SpanUnion / translate / widen / narrow / refit); it is not a U.Characteristic and MUST NOT appear in any CharacteristicSpace.

Legacy words (applicability / envelope / generality / capability envelope) MAY appear only as explanatory aliases in non‑normative notes.

Cross‑references. — C.2.3 (Unified Formality F) and C.2.2 (F–G–R): this pattern defines G as U.ClaimScope. — A.2.2 (Capabilities): capability gating now SHALL use U.WorkScope. — Part B (Bridges & CL): Cross‑context transfers MUST declare a Bridge with CL; CL affects R, not F/G. — Part E (Publication discipline; e.g., E.17 MVPK): publication views/cards/lanes MAY declare U.PublicationScope to bound where a publication is admissible; U.PublicationScope MUST NOT widen the underlying U.ClaimScope/U.WorkScope. (USM supplies the scope calculus; Part E supplies publication discipline.)

#Purpose & Audience

This pattern gives engineering managers and assurance architects one vocabulary, one model, and one set of operations to talk about where a claim holds and under which conditions a system can deliver a piece of Work. It removes the need to remember whether a document said “applicability,” a model said “envelope,” or a safety plan said “capability envelope.” Scope is scope. The only distinction that matters is what carries it:

• Knowledge/episteme → Claim scope (G).
• System/capability → Work scope (conditions under which Work at the promised measures is deliverable).

With USM, teams can:

• specify, compare, and compose scope without translation games;
• gate ESG and Method–Work steps with observable, context‑local scope checks;
• cross Contexts safely using Bridges and explicit CL penalties applied to R.

This pattern defines the scope mechanism (Context slices, set‑valued scopes, algebra, and guard usage) and the canonical lexicon (Claim scope (G), Work scope). It does not prescribe which Contexts must widen/narrow scope, nor which assurance levels are required; those are set by context‑local ESG and Method–Work policies, which SHALL reference the mechanisms defined here.

#Context

#Cross‑disciplinary pressures

Modern projects couple formal specs, data‑driven models, safety cases, and operational playbooks. Each artifact must say where it is valid—yet terminology drifts:

• Standards and specs often say applicability or scope.
• Modeling communities say envelope.
• Safety and performance documents speak about capability envelope.
• Knowledge patterns have used generality (G) as if it were “more abstract,” when we actually need “where the statement holds.”

#context‑local reasoning

FPF is context‑local: decisions, checks, and state assertions are valid inside a bounded context. Every practical question—Is this claim usable here? Can this capability deliver that Work now?—must be answered on a concrete slice of context (terminology, versions, environmental parameters, time selector Γ_time). USM provides a first‑class object for such slices and a single scope calculus atop them.

#Minimal, composable trust math

In F–G–R:

• F (formality) is “how strictly a claim is expressed” (C.2.3).
• G must be “where it holds,” not “how abstract it sounds.”
• R measures evidence and decays/penalties (freshness, CL).

When G is a set‑valued scope, composition becomes precise: serial dependencies intersect scopes; parallel, independently supported lines can publish a SpanUnion—but only where each line is supported.

#Problem

1. Synonym soup. Applicability, envelope, generality, capability envelope—different labels for the same mechanism led to mismatches in gating, review, and reuse.
2. Abstraction confusion. Calling G “generality” invited teams to treat “more abstract wording” as “broader scope,” silently masking unstated assumptions.
3. Split mechanics. Episteme vs system text used different algebra and guard language, though the same set operations were meant.
4. Cross‑context opacity. Transfers between Contexts lacked a shared carrier and a rule for what changes (trust) vs what stays (scope).
5. Overloaded words. Validity clashed with Validation Assurance (LA); operation/operational clashed with Work/Run in A.15, producing governance ambiguity.