#Part A - Kernel Architecture Cluster

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

#What this page is

This is generated FPF reference text from the specification preface or supporting sections. It helps interpret FPF; it is not FPF Reference product documentation.

#Methodology

Use it to understand how the specification wants to be read, then return to a route, pattern, or work packet for active work. Cite generated IDs only when the wording changes the task decision.

#Content

#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 an admissible problem-solving or search loop on day one. It explains the few terms you must publish when you generate, select, and ship declared set results or typed portfolio publications (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, typed portfolio publication, or set-return publication surface.

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

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

#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 and 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 declared set results and typed portfolio publications, not single scores, become the default publication.

#Forces

#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, typed portfolio publication, or set-return publication surface, it MUST surface N, U, C, Diversity_P, E/E‑LOG policy‑id, ReferencePlane, with units, scale, and polarity typed under MM‑CHR and CG‑Spec, and admissible references to DescriptorMapRef and 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 records. 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 architectural 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 first-day construction

1. Declare CG‑Frame (what “quality” means; admissible units and 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. Apply G.5 selection/dispatch with parity pins; return a declared set result (Front, Archive, Shortlist, or RankedShortlist as appropriate), not a single score or an unnamed "portfolio".
5. Publish to UTS + PathIds/PathSliceId; Illumination Map is report‑only telemetry by default.

#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. Declared retained set. {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 declared {environment, method} sets; 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 declared retained-set result or portfolio-publication view of methods per niche. (Publish UTS rows; cite Bridges + CL for cross‑domain reuse; edition‑pin Descriptor/Distance defs where QD applies.)

#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 declared set-result or typed portfolio publication where G‑kit mandates parity; illumination stays report‑only telemetry unless a CAL policy promotes it (policy‑id cited).

#Conformance Checklist (SCR/RSCR stubs)

#Consequences

Benefits. • Immediate usability for engineer‑managers (plain one‑liners) with formal anchors for auditors. • Declared-set-first / typed portfolio-publication culture (typed set results & 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 and scales → mitigated by CG‑frame templates.

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

#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/typed portfolio publication on the Core surface: N‑U‑C‑Diversity_P + policy‑ids; S/Scale‑probe where applicable; parity pins; lawful scales; declared-set publication where mandated. (Ties into UTS rows and parity records.) Editor’s cross‑reference. For agentic orchestration of scalable tool‑calls under BLP/SLL, see C.24 (Agent‑Tools‑CAL).

#Scope of this glossary

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.

#Early set-result and metric-kind vocabulary

• Use Palette for a plurality-preserving set with no dominance semantics yet.
• Use TraditionPalette only when the members are traditions gathered before later comparison or choice semantics are declared.
• For methods, hypotheses, environment-method pairs, candidate explanations, or other member kinds, use Palette plus explicit SubjectKind instead of borrowing the TraditionPalette head.
• Use Front only for a non-dominated set under one declared DominanceSet.
• Use Q-Front when the declared DominanceSet is the declared Q components.
• Use Archive for a retained set whose purpose is coverage, stepping-stone retention, or frontier expansion rather than current non-domination.
• Use ExplorationArchive for the broad retained exploration surface; it is the exploration-specific specialization of Archive.
• Use SteppingStoneSet only for one narrower retained subset whose stated purpose is future frontier reach rather than the whole archive. It is not part of the ordinary first-pass public-head family for retained exploration.
• Use Shortlist for the set chosen from one declared source set by one named lens.
• Use RankedShortlist only when that shortlist is explicitly rank-ordered.
• Use ShortlistId for the stable public token of one emitted shortlist; it is not the shortlist itself.
• Use ChoiceSet only when the mathematical set object underlying one shortlist must be named explicitly; do not let it replace the public shortlist head.
• Use Q-set for the declared current objective tuple that may ground the current DominanceSet.
• Use LearningProgressSignal for an optional policy-side signal that says further exploration is expected to improve capability or competence; it is not part of Q or dominance by default.
• Use CompetenceModelRef for the cited model or evidence surface that makes a capability or competence estimate reviewable.
• Use GoalSpaceExpansionCue for a declared reason to widen the goal or task palette; it is a pool-policy/probe cue, not proof that one candidate is already on the current front.
• Use GoalSpaceExpansionPolicyRef for the declared pool policy that says when learning-progress or competence evidence justifies widening goals, tasks, or curricula; it governs archive/curriculum growth, not default dominance.
• When future reach depends on transition or transfer potential, cite that reachability or transfer rule together with LearningProgressSignal, CompetenceModelRef, or GoalSpaceExpansionCue; keep that bridge on the archive/pool-policy side unless one explicit policy promotes it.
• If one front is meant to be current-Q by default, say so as Q-Front or as Front over the declared Q components rather than leaving the relation between Q-set and DominanceSet implicit.
• Use-Value may be one member of the Q-set only when the current Context declares it there; it is not the whole Q-set or the default Q-set by itself.
• Metric-kind doctrine: the Q-set is the candidate/front-facing objective tuple; Novelty@context is one context-relative candidate signal; DeltaDiversity_P is one set-relative marginal diversity contribution; IlluminationSummary is one report-only archive telemetry summary unless one explicit policy promotes it.
• Minimal mathematical lens: the current front lives in one declared comparison or outcome space, while the exploration archive may depend on one declared search, niche, or reachability space. Keep both spaces explicit when they differ.
• Keep Novelty@context, DeltaDiversity_P, Surprise, and IlluminationSummary outside the default Q-set unless one declared PromotionPolicy says otherwise.
• A reader should be able to tell whether one sentence is talking about a Palette, a Front, an Archive, a SteppingStoneSet, a Shortlist, or one explicit RankedShortlist, and whether one selected set came from one declared source set, before later policy or geometry detail arrives.
• Use portfolio only when the portfolio or set-result field is a declared retained set plus a selection/retention rule or a portfolio-publication posture. Do not use bare portfolio when Palette, Front, Archive, SteppingStoneSet, Shortlist, or RankedShortlist is already recoverable.

#Helper declarations for set-result language

• Ordinary public set-result family heads are Palette, TraditionPalette, Front, Q-Front, Archive, ExplorationArchive, Shortlist, and RankedShortlist.
• ExplorationArchive is the exploration-specific specialization of Archive; use Archive as the wider family head only when that exploration-specific subtype does not matter.
• SteppingStoneSet is one narrow retained-subset head only when that subset itself is the visible published surface; do not treat it as the ordinary public head for retained exploration.
• ShortlistId is the stable public token or id companion for one emitted shortlist; it is not a set-result family head.
• ChoiceSet is only the mathematical set gloss for a shortlist when that object itself must be named.
• SetResultFamily is a declaration field naming which public set-result family is being emitted; it is not another public head, not a publication face, not a publication form, not an interop publication form, and not a carrier kind.
• SourceSetFamily is a declaration field naming the immediate source-set family acted on by a lens, such as Q-Front, ExplorationArchive, Front, Archive, or TraditionPalette; it does not carry derivation, composition, or object-id load, it does not rename the emitted Shortlist or RankedShortlist, and it is not a publication face kind, publication form kind, interop publication form kind, or carrier kind.
• SourceSetComposition is an optional declaration field naming a multi-source composition such as Front+Archive when one lens genuinely acts over more than one declared source-set family; it is not itself a kind.
• SubjectKind is a declaration field naming what the members are, such as traditions, methods, hypotheses, environment-method pairs, candidate explanations, or other subject-kinded alternatives.
• EligibilitySet, DominanceSet, TieBreakerSet, and TelemetrySet are the comparison-bundle sets behind the published set result, not rival publication heads: EligibilitySet says what may enter, DominanceSet says what counts for current non-domination, TieBreakerSet says what may order or choose among survivors, and TelemetrySet says what may be reported without changing dominance.
• PromotionPolicy is the policy pin that authorizes one tie-breaker or telemetry signal to move into dominance. Without that pin, novelty, diversity, surprise, illumination, or similar signals remain outside the current DominanceSet.
• DerivedViewKind is an optional declaration field for a derived view, such as one tradition view used for interpretation or publication. It must leave the base SourceSetFamily, SetResultFamily, and emitted shortlist family recoverable.
• BasePaletteRef is an optional cited id/ref for the base palette when one derived tradition view or shortlist depends on that palette; it is a ref, not a kind.
• Stable values for SetResultFamily, SourceSetFamily, SourceSetComposition, SubjectKind, and DerivedViewKind should come from controlled tokens, cited ids, or already-declared head labels; do not let one ad hoc local prose label become a de facto field value.
• When the upstream object is SoTAPaletteDescription and its members are traditions, TraditionPalette may be used as the reader-facing tradition-only palette head for that same palette declaration. It is an aliasing head over the same palette declaration, not a separate palette declaration with its own authority-reference relation. When the members are not traditions, keep SoTAPaletteDescription or Palette + SubjectKind explicit instead of widening TraditionPalette.
• RetentionIntent=steppingStone is a field value on retained archive membership when the purpose is future frontier reach; it is not the same publication move as publishing a SteppingStoneSet, which names a narrower retained subset only when that subset itself is the published set result being discussed and not the default archive head.

#First public wording for shortlisted results

• When one reader needs the visible selected set, say Shortlist from <SourceSetFamily> under <LensId> rather than one generic choice set or portfolio.
• When the selected set must be cited as one stable emitted object, say ShortlistId and keep one nearby line that names the shortlist and its source set.
• When the shortlist is ordered, say RankedShortlist and keep the underlying shortlisted set result recoverable rather than jumping straight from Front to ranking.
• Use choice set underlying that shortlist only when the mathematical set object itself is the point of the sentence.
• A reader should be able to recover on first pass what source set was acted on, what shortlist came out, and whether the text is naming the published set result, the token, or the mathematical set object.

#Set/space reading reading glosses

The current set/space reading terms should read plainly as follows:

• SearchSpaceRef
  • one declared reference to the CharacteristicSpace currently used to search, compare, or navigate candidate possibilities
  • it is one role-named ref field over the existing CharacteristicSpaceRef / SpaceRef idiom, not one brand-new space kind
• OutcomeSpaceRef
  • one declared reference to the CharacteristicSpace currently used to judge outcomes, effects, or realized value
  • it is one role-named ref field over that same idiom, not one synonym for SearchSpaceRef
• DeclaredSubstrateInterpretiveView
  • the ordinary/common head of one optional interpretive-view family laid over one already-declared substrate-bearing line or one source set or one set result whose substrate remains recoverable
  • it helps the reader see the current inspection question; it does not replace the base source set or silently invent one new substrate
• DeclaredSubstrateAtlasView
  • one richer optional interpretive view that keeps several declared views, spaces, mappings, or qualifiers visible together
  • use it only when the current reading truly needs that composite interpretation, and say why thinner interpretation is not enough; it is not the default meaning of palette, front, archive, shortlist, or candidate set
• TypedSetViews
  • one explicit list of which declared set-view heads the current atlas/support reading is holding together
  • use it when several declared views must stay visible together; it does not create one new set result and should not hide the active source set or active set result
• OutcomeMapRef
  • one explicit OutcomeMapRef or named map ref that shows how one declared source or set result bears on into one outcome-side or effect-side declared space/ref when that map materially matters
  • it qualifies the reading; it does not rename the source set into the outcome-side declared space/ref
• SpaceMetricRef
  • one explicit metric-ref qualifier for the metric, neighborhood, distance, density, or reachability discipline being used inside one declared space
  • it qualifies how the reader is comparing positions in that space; it is not the space itself and not one substitute for SearchSpaceRef or OutcomeSpaceRef
• TransitionRelationRef
  • one explicit transition-ref qualifier for the transition, cross-scale state-change, dynamic-coupling, or phase-change basis that the reading depends on
  • it explains why motion or cross-scale state change is being read a certain way; it does not by itself decide policy, planning, or publication
• BridgeDistortionNote
  • one explicit note that a bridge, projection, aggregation, or derived reading is useful but not perfectly faithful
  • it tells the reader where comparability bends or information is lost, so a reading that claims bridge, substitution, or reliance beyond the declared note does not over-claim

#Practitioner-facing reading cue

• If the question is “Which space are we searching or navigating?”, look for SearchSpaceRef.
• If the question is “Which space are we judging outcomes in?”, look for OutcomeSpaceRef.
• If the question is “What optional overlay helps me read several declared views or set results together?”, look for DeclaredSubstrateInterpretiveView.
• If that overlay also keeps several declared views, spaces, mappings, or qualifiers together, it is the richer DeclaredSubstrateAtlasView.
• If the atlas/support reading must keep several declared set views visible at once, look for TypedSetViews.
• If the overlay depends on one explicit source-to-outcome mapping, look for OutcomeMapRef.
• If the overlay depends on one metric, neighborhood, or reachability discipline inside one declared space, look for SpaceMetricRef.
• If the overlay depends on one transition, cross-scale state-change, or dynamic-coupling basis, look for TransitionRelationRef.
• If the overlay depends on one bridge or projection that may lose fidelity, look for BridgeDistortionNote.

#First-use classification check

• Start with DeclaredSubstrateInterpretiveView when the NQD/OEE task is simply to keep one declared palette, front, shortlist, or archive readable while comparing candidate material.
• Start with it only when any cited SearchSpaceRef, OutcomeSpaceRef, mappings, or qualifiers are already declared elsewhere and remain recoverable through the base substrate, source set, or set result.
• Escalate to DeclaredSubstrateAtlasView only when the reading must hold several declared views, spaces, mappings, or qualifiers together to explain why one specialization, evaluation, or boundary judgement stays admissible, and state why thinner interpretation is insufficient.
• If the reading keeps several declared set views together, name TypedSetViews explicitly instead of letting atlas wording hide that view-set choice.
• If the reading depends on one source-to-outcome map, name OutcomeMapRef explicitly instead of letting the overlay silently stand in for that map.
• If the reading depends on one metric or neighborhood discipline, name SpaceMetricRef explicitly instead of letting the space name stand in for that metric.
• If the reading depends on one transition, cross-scale state-change, or dynamic-coupling basis, name TransitionRelationRef explicitly instead of letting the overlay silently absorb that transition-support requirement.
• Not this glossary-side interpretive-view stack when the real move is to invent one new search doctrine, one new outcome metric family, or one new publication surface. Those decisions stay with the governing patterns for the object itself.

#A.0:End

#U.Holon, U.System, and U.Episteme

Type: Part A architectural ontology pattern Status: Stable Normativity: Normative unless a section is explicitly informative

#Use This When

Use this pattern when a project must say what kind of thing is under concern before it can discuss parts, boundaries, interactions, roles, work, architecture, or descriptions.

Typical moments:

• a team calls everything a "system" and then tries to ask physical questions about theories, documents, models, or descriptions;
• an episteme is treated as an acting agent that performs work or makes decisions;
• a group, organization, model, document set, machine, neural-network architecture, or research program must be treated as a whole with parts;
• a set of items is expected to act, but no boundary, part-whole relation, or acting system has been named;
• architecture or structure claims need a grounding holon before selected structures can be described.

First useful move. Decide whether the subject is only a U.Entity, a U.Holon, a U.System holon, or a U.Episteme holon in the current bounded context.

What goes wrong if missed. A theory gets ports, a document edits itself, a list becomes an acting organization, and architecture is discussed without naming the holon whose structure is being selected.

What this buys. FPF gets one compact root for composition: identity starts at U.Entity; part-whole composition starts at U.Holon; acting work attaches to U.System; claim-bearing knowledge is carried by U.Episteme without making it an agent.

Not this pattern when.

• If the current question is local vocabulary, role assignment, or meaning inside one semantic frame, use A.1.1 and the role-governing patterns.
• If the current question is the episteme slot relation, use C.2.1.
• If the current question is selected structure over a holon, use A.22.
• If the current question is architecture of a holon in context, use C.30.
• If the current question is work, method, or role-method-work alignment, use A.15 and its dependent patterns.

#Problem Frame

FPF cannot use system as its universal root. A pump, a theory, a software product, a legal code, a dashboard, a research program, and a team can all be objects under concern, but they do not all act, exchange matter, have physical ports, or execute methods.

The root distinction is:

• U.Entity: something that can be individuated and referenced;
• U.Holon: an entity that is usable as a whole with parts and as a part within larger wholes;
• U.System: an acting physical or operational holon;
• U.Episteme: a claim-bearing, non-agentive holon.

A.1 governs this holonic ontology. It lets FPF talk about composition and boundaries across systems and epistemes without building a second ontology from the words "object", "system", "document", "model", "theory", or "architecture".

#Problem

Without A.1:

1. System-bias spreads. Physical assumptions are projected onto epistemes, descriptions, theories, and documents.
2. Epistemes become agents. A document, theory, model, or pattern is said to decide, perform, authorize, promise, or edit itself.
3. Collections become collectives by wording. A set of people, services, files, or claims is treated as an acting whole without a boundary and role assignment.
4. Architecture loses its grounding holon. A structure or architecture claim floats free of the holon whose structure is being selected.
5. Part-whole reasoning is applied too early. A bare entity is given parts, components, and aggregation before it is modeled as a holon.

#Forces

#Solution

Use the A.1 holon stack:

U.Entity
  U.Holon
    U.System
    U.Episteme

This is not a publication hierarchy. It is the root ontology for cross-domain composition in FPF.

#U.Entity

U.Entity is anything that can be individuated and referenced under a bounded context. It carries no part-whole assumption by itself.

Use U.Entity when the current move only needs to point to a thing: a number, a claim, a named product, a material batch, a data value, a legal clause, a role value, a source reference, or another object under concern.

Do not apply holon aggregation, membership tests, or acting-system roles to a bare U.Entity unless the current pattern also models it as a U.Holon or a subtype of U.Holon.

#U.Holon

U.Holon is a U.Entity treated as a whole with parts and as a participant in larger wholes under a bounded context.

The A.1 holon slot relation is:

HolonSlotRelation:
  holonIdentity:
  boundedContextRef:
  boundaryRef:
  partRelationSet:
  containingWholeRef?
  interactionSet?
  subtypeKind?: U.System | U.Episteme | other accepted subtype
  selectedStructureRef?

The boundary is current for the bounded context. A holon may have several possible boundary descriptions across contexts or viewpoints, but one current holon use must say which boundary governs the claim being made.

partRelationSet names the part-whole relations current for the use. Under open-world discipline, an omitted part list means "not recovered or not current for this claim", not "there are no parts."

#Boundary and Interaction

U.Boundary delimits the holon from its environment in the current bounded context.

U.Interaction names what crosses that boundary when such crossing is current: matter, energy, information, control signal, material flow, document transfer, claim update, or another governed crossing kind.

Do not call every boundary an interface. Use interface language only when a governing module, signature, mechanism, architecture, or boundary pattern makes interface meaning current.

#Holon Membership Test

When a candidate part is contested, use the holon membership test:

1. Dependency: removing the candidate breaks a core invariant of the holon.
2. Internal interaction: the candidate participates in interactions within the holon boundary that matter for the current claim.
3. Emergence: the candidate contributes to a collective property that justifies treating the whole as one holon.

Passing one or more tests can justify part membership for the current claim. Failing all three keeps the candidate outside the holon boundary for that claim.

#U.System

U.System is a holon that can act physically or operationally. It can bear roles, enact methods, perform work, participate in mechanisms, maintain state, transform other entities, and produce effects.

Use U.System when the current claim needs acting-system eligibility:

• role assignment to a system in a bounded context;
• method enactment or work occurrence;
• physical or operational boundary crossing;
• system architecture or selected structure;
• mechanism realization or transformer participation.

A collective system is not the same as a set. If a group of people, machines, services, or agents is expected to act, model the acting whole as a U.System with a boundary and role assignments. If no acting whole is claimed, keep it as a set or collection under the governing relation.

#U.Episteme

U.Episteme is a holon whose parts are claim-bearing and interpretation-bearing values: claims, definitions, reference schemes, viewpoints, evidence relations, argument structures, model content, or other episteme components governed by C.2.1.

U.Episteme is non-agentive. It does not decide, promise, authorize, perform work, or revise itself. A system in role may write, revise, publish, compare, transform, or use an episteme. The episteme remains the claim-bearing holon under the C.2.1 slot relation.

An episteme can be an EntityOfConcern. This does not make it an acting system. It means the current description, evaluation, architecture claim, or transformation claim is about that episteme as the subject under concern.

#Cross-Level Use

The same project object can appear at different levels without changing kind by wording:

• a system can fill GroundingHolonSlot in an episteme description;
• an episteme can be the EntityOfConcern of another episteme;
• a system can publish or transform an episteme;
• a selected structure can be about a system, episteme, organization, document set, model, or research program when that object is treated as a holon.

Slot position does not create a new kind. A system filling a role-assignment holder slot remains a system. An episteme filling an EntityOfConcern slot remains an episteme. A holon whose structure is described does not become the description of that structure.

#Archetypal Grounding

#Water Pump as U.System

Pump #37 is a U.System holon in a maintenance bounded context.

HolonSlotRelation:
  holonIdentity: Pump #37
  boundedContextRef: plant maintenance context
  boundaryRef: casing plus inlet and outlet flanges
  partRelationSet: motor, impeller, seals, housing
  containingWholeRef: cooling-water subsystem
  interactionSet: water flow, electrical energy, control signal
  subtypeKind: U.System

The pump can bear a maintenance role, enact a repair method, perform work through technicians and tools, and have selected structures such as transformation-flow, control, or module-interface structure.

#Scientific Theory as U.Episteme

Newtonian gravitation as taught in one edition is a U.Episteme holon in a physics-education bounded context.

HolonSlotRelation:
  holonIdentity: Newtonian gravitation in the selected edition
  boundedContextRef: physics education context
  boundaryRef: selected axioms, vocabulary, reference scheme, and admissible claim set
  partRelationSet: definitions, laws, derivations, examples, evidence relations
  containingWholeRef: mechanics curriculum episteme
  interactionSet: citation, teaching, model-use, revision, publication
  subtypeKind: U.Episteme

The theory does not teach itself or revise itself. A teacher, author, student, reviewer, or software system in role may publish, explain, compare, or modify an episteme. The episteme carries claims and relations; the acting system performs the work.

#Team as Collection or Collective System

A list of named engineers is a collection. It becomes a U.System only when the project claims an acting whole: boundary, membership rule, coordination structure, role assignments, decision method, and work occurrences are current.

If the project says "the team approved the architecture", A.1 asks whether there is a collective system and whether a decision pattern or governance pattern makes that claim admissible. If not, name the specific system-in-role or decision relation that actually carries the claim.

#Bias-Annotation

Lenses tested: Onto, Arch, Epist, Prag, Gov, Did.

This pattern intentionally resists:

• system-bias: treating all objects as acting physical systems;
• episteme-agent bias: assigning work, authority, or decision to claim-bearing epistemes;
• collection-bias: treating any set as an acting collective;
• boundary-bias: choosing boundaries for convenience or politics without a membership test;
• publication-form bias: treating a document, diagram, or model publication as the holon it describes.

#Conformance Checklist

#Common Anti-Patterns and How to Avoid Them

#Consequences

Positive consequences:

• FPF can talk about physical systems, organizations, documents, theories, models, and research programs under one composition root without making them all systems.
• Acting work stays attached to systems in roles.
• Epistemes can be described, compared, published, and transformed without becoming agents.
• Architecture and selected-structure claims gain a grounding holon.

Costs:

• Authors must stop using "system" for every object under concern.
• A holon boundary must be named when part-whole or architecture claims rely on it.
• Some familiar sentences need repair: "the document decided" becomes a claim about a system in role, a decision relation, and an episteme or publication.

#Rationale

The A.1 stack prevents category errors by separating individuation, composition, acting eligibility, and claim-bearing. U.Entity gives the minimal "something under concern" without part assumptions. U.Holon adds composition and boundary. U.System adds acting eligibility. U.Episteme adds claim-bearing structure without agentivity.

This also prevents ontology duplication. A theory under concern, a theory description, a publication of that description, and the system that edits the publication can all be named without turning each slot position into a new kind. The same discipline is needed by architecture: architecture is selected structure of a holon in context, not a diagram and not a floating root kind.

The older phrase "entity to holon to system or episteme" remains useful only when read as this typed stack. It is not a process sequence and not a rule that every entity must become a holon.

#SoTA-Echoing

Source role and currentness: the compositional open-systems and systems-engineering rows are current support for boundary-consistent grounding; bounded-context practice is carried through A.1.1; FAIR, provenance, and knowledge-representation practice support the separation among claim-bearing epistemes, publications, and acting systems. Older named traditions under these families are lineage or background unless a governing pattern cites them by value. Reopen A.1 when accepted FPF work or current systems, KR, provenance, or digital-twin practice changes the root split among U.Entity, U.Holon, U.System, U.Episteme, boundary, or publication-form separation; do not reopen it for a new tool, notation, or diagram style that does not change that root ontology.

#Relations

• Builds on: E.24 for ontic introduction discipline and A.6.5 for slot relation discipline.
• Coordinates with: A.1.1 for bounded context, A.22 for selected structure, C.30 for architecture, C.2.1 for episteme slot relation, A.15 for role-method-work alignment, E.24.PUB for holon-description publication boundary, and E.10.ARCH for wording-use restoration.
• Used by: patterns that need a grounding holon, acting system, non-agentive episteme, part-whole relation, or collection-versus-collective distinction.

#Footer Marker

#A.1:End

#U.BoundedContext Semantic Frame

Type: Part A architectural ontology pattern Status: Stable Normativity: Normative unless a section is explicitly informative

#Use This When

Use this pattern when a term, role, rule, invariant, unit, status, or admissible inference is meaningful only inside a named semantic frame.

Typical moments:

• the same word means different things in engineering, finance, legal, scientific, or operations work;
• a role assignment needs the context that defines the role and its incompatibilities;
• an invariant is local to one standard, team, theory, regulation, product line, or edition;
• two contexts need a bridge relation rather than an assumed global equivalence;
• a "domain" label is too broad to decide local vocabulary or rules.

First useful move. Name the U.BoundedContext that governs the current meaning, then state the local vocabulary, local invariants, role taxonomy when role assignments are current, episteme-use/status relations when epistemic-use or status claims are current, and bridge relations that matter for the claim.

What goes wrong if missed. "Owner", "ticket", "service", "evidence", "role", "done", and "valid" become global labels. Integration work then appears to be about matching words, while the real problem is unspoken semantic frames.

What this buys. FPF can keep plural meanings without contradiction: each meaning is local, and cross-context use becomes an explicit bridge relation with stated fit and loss.

Not this pattern when.

• If the question is only naming a durable term, use F.18.
• If the question is role-method-work alignment after the context is known, use A.15.
• If the question is episteme description context, use C.2.1 with BoundedContextRef.
• If the question is a broad field such as healthcare, physics, finance, or architecture, treat it as an informative domain family unless a specific bounded context is named.

#Problem Frame

Meaning is local. The same expression can be coherent in one bounded context and misleading in another. "Service" in software, service operations, military organization, and contract law is not one global object by spelling. "Evidence" in a courtroom, a scientific review, a machine-learning benchmark, and a gate review is not one global role by spelling.

U.BoundedContext is the FPF ontic for this locality of meaning. It is a U.Holon that holds one semantic frame: local vocabulary, local invariants, local role taxonomy when role-assignment claims are current, local episteme-use/status relations when epistemic-use or status claims are current, and bridge relations to other contexts.

A bounded context is not an enclosing object for all work in a domain. It is the semantic frame in which a term, rule, role assignment, or inference is interpreted.

#Problem

Without U.BoundedContext:

1. Semantic drift hides in shared words. Teams keep the same label while changing the object, role, rule, or allowed inference.
2. Local rules leak globally. A policy, status, role, or invariant valid in one context is applied in another without a bridge relation.
3. Pluralism looks like contradiction. Two contexts can each be coherent, but absent context they look mutually inconsistent.
4. Role assignments lose their footing. A U.Role is used as a global label rather than a value defined in a local role taxonomy.
5. Domain labels pretend to govern. "Healthcare", "AI", "architecture", or "physics" is used where a specific semantic frame is required.

#Forces

#Solution

Model U.BoundedContext as a semantic-frame holon.

BoundedContextSlotRelation:
  contextIdentity:
  contextBoundary:
  localVocabulary:
  localInvariantSet:
  localRoleTaxonomy?:
  localEpistemeUseAndStatusRelationSet?:
  bridgeRelationSet?:
  stewardingSystemOrCommunityRef?:
  editionOrWindowRef?:

The context is the EntityOfConcern when the claim is about semantic locality itself. It may also fill BoundedContextRef in role assignments, episteme descriptions, characteristic spaces, architecture descriptions, and other patterns.

#Context Identity

contextIdentity names the semantic frame, not a territory, department, document, storage place, team, or domain family.

Good context names are specific enough to decide meaning:

• Hospital.OR_2025
• BPMN_2_0
• Theory.SpecialRelativity.SelectedEdition
• FactoryLineB.MaintenanceRules.2026
• FPF.PatternQuality.E21

Broad labels such as "healthcare", "physics", "software", "workflow", or "architecture" are informative domain families unless they are narrowed into a bounded context with local vocabulary, invariants, the relevant role taxonomy or episteme-use/status relation set, and bridge relations.

#Context Boundary

contextBoundary says where local meaning holds. It can be bounded by edition, standard, organization, product line, theory, practice, regulation, contract, operating mode, or another governed boundary.

The boundary is not a document boundary by default. A document may publish a context description. The context is the semantic frame that the document describes.

#Local Vocabulary

localVocabulary gives local senses for terms. It does not create global meanings.

When a word crosses contexts, do not infer sameness from spelling. Use a bridge relation with direction, relation kind, fit, loss, and scope.

Example: ticket in an airline context may denote a travel authorization; ticket in an IT service context may denote a work item. Those are different local meanings unless a bridge relation is declared for a specific use.

#Local Invariant Set

localInvariantSet names rules that hold inside the context.

Examples:

• in a hospital operating-room context, one person cannot fill surgeon and independent auditor roles for the same case;
• in a workflow-standard context, one work item cannot move from InProgress to Done without an accepted review transition;
• in a theory context, selected postulates constrain admissible derivations.

An invariant does not become global because it is well written. Cross-context reuse requires a bridge relation or a new local declaration.

#Local Role Taxonomy

localRoleTaxonomy defines U.Role values valid in the context when system-role assignments are current. A U.RoleAssignment uses one context:

RoleAssignment:
  holderRef:
  roleRef:
  boundedContextRef:
  windowRef?:

The same holder may have different role assignments in different contexts. The same role name may denote different roles in different contexts. A "global role" is not a valid shortcut; it is either a role value defined in a selected context or a wording problem to repair.

Do not put postulate, evidence, derived-claim, publication, or status distinctions into localRoleTaxonomy merely because ordinary language calls them "roles". When the context governs epistemic use or status, record those distinctions in localEpistemeUseAndStatusRelationSet and apply the direct evidence-use, source-use, status-use, claim, publication, or gate pattern.

#Bridge Relation Set

bridgeRelationSet records cross-context relations. A bridge is not a hidden merge. It states how a meaning, role, rule, unit, status, or claim in one context relates to one in another context.

A bridge relation should state:

BridgeRelation:
  sourceContextRef:
  targetContextRef:
  sourceValueRef:
  targetValueRef:
  relationKind:
  direction:
  fit:
  loss:
  scope:

If a bridge cannot be stated, the cross-context use remains unsupported for that claim.

#Non-Enclosing Boundary

Do not use bounded context as an enclosing object for everything nearby. A bounded context localizes meaning; it does not automatically contain every system, document, team, work plan, source, or architecture that mentions its vocabulary.

Objects can be governed by, described under, interpreted inside, or bridged across a context without being parts of the context holon. Use the relevant slot relation for each claim.

#Archetypal Grounding

#Hospital Operating Room Context

Hospital.OR_2025 is a bounded context for operating-room work in a named hospital edition.

BoundedContextSlotRelation:
  contextIdentity: Hospital.OR_2025
  contextBoundary: operating-room policy and procedure edition for 2025
  localVocabulary: case, sterile field, time-out, circulating nurse, independent auditor
  localInvariantSet: time-out required before incision; surgeon and independent auditor roles incompatible for one case
  localRoleTaxonomy: SurgeonRole, ScrubNurseRole, CirculatingNurseRole, IndependentAuditorRole
  bridgeRelationSet: billing-code bridge, hospital-wide staffing bridge

The context does not perform surgery. Systems in roles perform work. The context defines the local meanings and constraints under which those role assignments and work claims are interpreted.

#Special Relativity Context

Theory.SpecialRelativity.SelectedEdition is a bounded context for a selected episteme tradition.

BoundedContextSlotRelation:
  contextIdentity: Theory.SpecialRelativity.SelectedEdition
  contextBoundary: selected postulates, vocabulary, reference schemes, and admissible derivations
  localVocabulary: inertial frame, proper time, Lorentz transformation
  localInvariantSet: constant light speed postulate; covariance constraints
  localRoleTaxonomy: not current for theory claims
  localEpistemeUseAndStatusRelationSet: postulate-status relation; evidence-use relation; derived-claim status relation
  bridgeRelationSet: bridge to Newtonian mechanics under low-speed approximation; bridge to general relativity under selected assumptions

The context frames meaning. It does not make the theory true by itself and does not act. Systems in roles publish, teach, test, or revise epistemes that use this context.

#FPF Pattern Quality Context

FPF.PatternQuality.E21 is a bounded context for evaluating FPF pattern quality. Terms such as "recognition text", "assurance text", "semio-bias resistance", and "first-use affordability" have local meanings. A different context may use "quality" for product reliability, manufacturing yield, safety assurance, or service satisfaction.

Cross-context reuse of a quality term requires a bridge relation. Spelling alone does not carry the meaning.

#Bias-Annotation

Lenses tested: Onto, Epist, Prag, Gov, Arch, Did.

This pattern intentionally resists:

• global-language bias: one spelling is treated as one meaning everywhere;
• domain-family bias: a broad field label is treated as if it governed local meaning;
• enclosing-object bias: the context is treated as a storage place or enclosing object for all related work;
• role-globalization bias: a role name is used without the context that defines it;
• bridge-erasure bias: cross-context fit and loss are hidden behind "same", "equivalent", or "mapped" language.

#Conformance Checklist

#Common Anti-Patterns and How to Avoid Them

#Consequences

Positive consequences:

• Polysemy becomes governable: meaning is local and bridgeable rather than globally guessed.
• Role assignments become inspectable because the role taxonomy is named by context.
• Local invariants stop leaking into other contexts.
• Domain-family labels remain useful for orientation without becoming false kernel objects.

Costs:

• Authors must name a context when they use polysemous terms.
• Cross-context claims need bridge relations instead of "obvious" equivalence.
• Some old context hierarchies need repair into explicit bridges or domain-family metadata.

#Rationale

U.BoundedContext is the semantic companion to U.Holon. A holon boundary says what counts as inside or outside the whole for a claim. A bounded-context boundary says where vocabulary, invariant, role taxonomy, episteme-use/status relation set, and inference rule are locally coherent when those claims are current.

The pattern is generalized from domain-driven design but is not software-only. Scientific theories, legal standards, hospital procedures, manufacturing cells, model cards, research programs, and FPF evaluation contexts all need local meaning. FPF makes that locality an ontic rather than leaving it as "it depends."

This also protects role and episteme ontology. A U.Role is not global; it is valid inside a bounded context. A U.Episteme is meaningful only when its EntityOfConcern, viewpoint, reference scheme, and bounded context are known. Bridges then make cross-context correspondence explicit instead of letting spelling decide.

#SoTA-Echoing

Source use and currentness: domain-driven bounded-context practice is the selected practice lineage generalized beyond software; team-topology and socio-technical boundary practice are current context for stewarding-system and cognitive-boundary caution; data-mesh and interoperability practice motivate explicit bridge relations; FAIR, provenance, and research-object practice motivate interpretation context and publication-boundary discipline. Reopen A.1.1 when current practice or accepted FPF work changes the criteria for semantic locality, cross-context bridge fit and loss, local role taxonomy, local episteme-use/status relation set, or context-publication separation; do not reopen it for a new domain label, team structure, metadata format, or data product style that leaves those criteria unchanged.

#Relations

• Builds on: A.1 for U.Holon, E.24 for ontic discipline, and A.6.5 for slot relation discipline.
• Coordinates with: A.15 for role-method-work alignment, C.2.1 for episteme slot relations, F.9 for bridge relations, E.10 and E.10.ARCH for context-word repair, and E.24.PUB for bounded-context description and publication boundary.
• Used by: role assignments, episteme descriptions, characteristic spaces, architecture descriptions, method descriptions, source interpretations, and any FPF claim whose terms depend on local meaning.

#Footer Marker

#A.1.1:End

#Role Taxonomy

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

#Use This When

Plain name. Work-facing role value.

Use this pattern when a project needs to say what a system, organization, person, team, tool, agent, machine, or other acting holon is being in a bounded context before method, plan, work, evidence, responsibility, or naming claims can be made safely.

Typical moments:

• a project sentence says "engineer", "reviewer", "operator", "supplier", "model verifier", "agent", "service provider", or another role-like name, and it is unclear what holder, context, and work claim are current;
• a team treats a role name as if it created capability, commitment, obligation, permission, method, work, or evidence;
• a standard, report, dataset, model card, publication, requirement, or definition is described as having a "role" in evidence, status, assurance, source use, or publication use;
• a method, plan, work occurrence, or result is attributed to a role without naming the holder and role assignment under which the work is performed;
• role names must be kept reusable across contexts without making each context-local role into a new system kind.

Primary EntityOfConcern. The EntityOfConcern is U.Role: a context-bound role value in the role ontologicalNeighborhood. A role value names what an acting system or acting holon is being for a bounded context. It is not the holder, not the assignment relation, not a capability, not a method, not a work occurrence, not a commitment, not an obligation, not a permission, not a description, and not a slot kind.

Primary working reader. The first reader is an engineer-manager, analyst, or FPF author who must separate role value, holder, role assignment, method, plan, work, evidence, and source-use claims before acting or writing a pattern. The downstream reader is the project participant who needs role language to answer who held what role, in which context, for which claim.

First useful move. Name the role value, the bounded context, and whether the current claim is about role identity, a role assignment, role description, role state, role relation structure, capability requirement, method requirement, planned work, performed work, or an episteme used as evidence, source, standard, requirement, definition, explanation, status bearer, or publication.

What goes wrong if missed. Role words become an ontology shortcut. A document becomes a "verifier role"; a capability becomes a role; a role name is treated as evidence that work happened; a method is treated as a role's hidden behavior; a publication is treated as if it acted. FPF then grows a second role ontology for epistemes, status labels, access labels, relation arguments, and source labels.

What this buys. A small role vocabulary can serve many projects without type explosion. The same system can hold different roles in different contexts; work remains performed by a holder under a role assignment; epistemes remain used through their own evidence, status, source, publication, requirement, definition, explanation, and assurance relations.

Not this pattern when.

• If the current claim is the assignment relation linking holder, role, context, and window, use A.2.1.
• If the current claim is capability, use A.2.2.
• If the current claim is role state, use A.2.5.
• If the current claim is role-requirement substitution, incompatibility, qualification, or bundles, use A.2.7.
• If the current claim is method, method description, work plan, or performed work alignment, use A.15.
• If the current claim is an episteme used as evidence, source, standard, definition, requirement, explanation, status bearer, publication, or assurance input, use the direct evidence-use, status-use, source-use, publication-use, requirement-use, definition-use, explanation-use, or assurance pattern. Do not force it through U.Role.
• If the current issue is only a confusing role-like word, first use A.6.RSIR to recover the governed object or claim kind.

#Problem Frame

FPF needs role language because the same holon can be used, treated, expected, or named differently in different bounded contexts. A pump can be a cooling circulator in one plant context and a test article in another. A person can be verifier in one work package and author in another. A service can be supplier in one agreement-like relation and consumer in another. Without a role value, these contextual uses either become new system subtypes or remain vague source language.

At the same time, role language is dangerous. Everyday phrases such as "the role of this standard", "the role of this dataset", "the role of this theorem", "the role of this dashboard", or "the role of this interface" can hide several different FPF claims. They may be evidence-use, source-use, publication-use, status-use, requirement-use, explanation-use, interface, signature, capability, method, or work claims. They are not automatically U.Role claims.

A.2 therefore keeps U.Role real, but narrow. A role is a work-facing context-bound role value. It becomes operational through neighboring relations, especially U.RoleAssignment in A.2.1 and role-method-work alignment in A.15. It does not absorb every relation in which a value participates.

#Problem

Without this pattern:

1. Type explosion returns. Each contextual use becomes a new system kind such as PumpAsCoolingCirculator or ReviewerReportSystem.
2. Role and assignment collapse. The role value, the holder, the context, and the time window are treated as one vague label.
3. Role and capability collapse. A role name is treated as if it created ability.
4. Role and method collapse. A role name is treated as if it contained the method by which work is done.
5. Role and evidence collapse. A document, dataset, standard, proof, or model card is treated as a role holder because it is used as evidence or source material.
6. Role and work collapse. A role label is treated as evidence that work was performed.
7. Argument-position drift appears. "Role" is used for relation argument positions or slot positions, competing with A.6.5 SlotSpec discipline.

#Forces

#Solution

Use U.Role as a context-bound role value, not as a generic contextual classifier.

U.Role answers the question: what is this acting system or acting holon being, in this bounded context, for the current work-facing claim?

It does not answer by itself:

• who holds the role;
• whether the holder can do the work;
• which method is selected;
• which work was planned or performed;
• which evidence justifies a claim;
• which publication or description expresses the role;
• which status applies to a document, method, result, or claim;
• which relation argument position or SlotKind is current.

Those claims belong to neighboring patterns.

#Core Definitions

U.Role. A U.Role is a context-bound role value: a reusable value that names what an acting system or acting holon is being in a bounded context. It is work-facing because its primary practical use is to govern or explain role assignment, method requirements, work attribution, role-state checks, role naming, and role-related evidence about work.

Plain gloss: a role is a contextual functional mask. The gloss is helpful only if the normative object stays clear: the role value is not the holder and not the work.

U.RoleAssignment. A U.RoleAssignment is a typed assignment relation value governed by A.2.1. It links a holder, a U.Role, a bounded context, and any current assignment window. A.2 names why this relation is needed; A.2.1 governs its SlotSpecs.

Role holder. A holder of a U.RoleAssignment is a U.System or acting holon admitted by the governing work or method pattern as a system-like performer for the bounded context. An episteme is not admitted as holder merely because it is used as evidence, source, standard, requirement, definition, explanation, status bearer, publication, or assurance input.

Role description. A role description is an episteme that describes, constrains, teaches, publishes, or stores a role value or role assignment. The description is not the role value by default.

Role relation-neighborhood. A role value is surrounded by relations that are not parts of the role:

Do not turn every relation in this neighborhood into a slot of U.Role. Use SlotSpec discipline only when the governing pattern declares a slot-bearing relation.

#Work-Facing Role Assignment Boundary

Use the short readable notation only as a notation for a typed assignment relation:

Holder#Role:Context@Window

The normative assignment relation is governed by [A.2.1](/generated/patterns/A.2.1), not by the notation. Its core slots are:

RoleAssignmentCoreSlotSpec:
  HolderSlot:
  RoleValueSlot:
  BoundedContextSlot:
  AssignmentWindowSlot:

HolderSlot is filled by a U.System or acting holon admitted as system-like performer for the current work or method claim.

RoleValueSlot is filled by U.Role.

BoundedContextSlot is filled by the context that gives the role value its local meaning.

AssignmentWindowSlot is filled when assignment currentness, work attribution, role-state admission, or source freshness depends on a window. An open-world missing slot means unknown, not asserted, not recovered, or not current for this claim; it does not mean no such value exists.

Direct work-role patterns may add work-role qualifier slots. Evidence-use and status-use slots are not work-role qualifier slots and do not belong in assignment provenance.

#What Does Not Become U.Role

The following are not role values merely because source language says "role":

If the direct kind is not yet clear, use A.6.RSIR.

#Role Taxonomy Inside a Bounded Context

Inside one bounded context, roles may be organized by:

• role-requirement substitution;
• role incompatibility;
• role bundles;
• role-state predicates;
• holder eligibility constraints;
• capability requirements;
• method requirements or exclusions;
• naming and description conventions.

A.2.7 governs role relation structure. It is context-local role architecture in life, not mereology, not class subsumption for systems, not generic concern algebra, not MethodRelationStructure@BoundedContext, and not method algebra. Algebraic, graph, matrix, embedding, or neural descriptions are only lenses over selected role relation structure when a project explicitly uses them.

Typical work-facing role families include:

Domains may define roles such as CoolingCirculatorRole, BridgeInspectorRole, ClinicalTrialCoordinatorRole, ModelCardReviewerRole, or ShipyardOperatorRole. Define them in their bounded context and connect them to role assignment, capability, method, work, and evidence only when those claims are current.

#Reduced Use and Reopen Conditions

A role-like word may stay in reduced use when it only helps people recognize a local conversation and no claim depends on holder, assignment, context, time, capability, method, work, evidence, status, source, publication, or gate use.

Use the fuller role pattern when a claim based on the role-like word would change what can be done, claimed, checked, relied on, or attributed:

• use A.2 when the role value itself, bounded context, role taxonomy, or role relation-neighborhood is current;
• use A.2.1 when holder, role value, context, window, assignment source, or work-role qualifier is current;
• use A.2.2 when ability or capability is current;
• use A.2.5 when role-state admission, currentness, or role-state gate is current;
• use A.2.7 when role-requirement substitution, incompatibility, qualification, or role bundles are current;
• use A.15 when method, method description, work plan, or performed work is current;
• use direct episteme-use patterns when evidence, status, source, publication, requirement, definition, explanation, assurance, or gate use of an episteme is current;
• use A.6.5 when the word "role" is only a relation position or SlotKind.

If a reduced-use role label is later used for a stronger claim, do not treat the earlier reduced use as evidence. Recover the needed role value, assignment relation, neighboring value, or direct episteme-use relation before the stronger claim is made.

#Archetypal Grounding

#Pump in a Cooling Loop

PumpUnit-3#CoolingCirculatorRole:Plant-A@2026-06-01..open

The holder is PumpUnit-3, a system. The role value is CoolingCirculatorRole. The context is Plant-A. The assignment window is open from a named date.

This does not say the pump has the capability to circulate under every condition. Capability claims stay under [A.2.2](/generated/patterns/A.2.2). It does not say which method is used or which work occurred. Method, method description, work plan, and work claims stay under [A.15](/generated/patterns/A.15).

#Standard Used in Design Work

"RFC-9110 has the protocol-standard role in this design" is source-side wording that must be repaired.

Current FPF expression:

• the RFC publication is an episteme or publication used as source, standard, requirement, or method-description source;
• the design service, engineer, or team is the system or acting holon holding any work-facing role;
• the design work is performed by that holder under a role assignment;
• the RFC does not perform the work and does not hold U.Role.

#Reviewer and Review Report

A person, team, or agent service can hold ReviewerRole for a review context. The review report produced by that work is an episteme. Later, another project may use the report as evidence or status input. That use is an evidence-use or status-use relation around the report, not a role assignment to the report.

#Relation Argument Named "Role"

In a relation signature, "role" may mean an argument position. If the claim is about a relation position, use A.6.5 SlotSpec discipline. Do not create a U.Role merely because the source says "argument role".

#Bias Annotation

#Working Guidance

1. Start with the source phrase and recover the current project concern.
2. If the phrase names what an acting system or acting holon is being in a bounded context, recover a U.Role value.
3. If the phrase names the holder-role-context-window relation, recover U.RoleAssignment under A.2.1.
4. If the phrase names ability, recover capability under A.2.2.
5. If the phrase names performed work, intended work, or governing method, use A.15 and its neighboring method and work patterns.
6. If the phrase names evidence, source, standard, requirement, definition, explanation, publication, status, assurance, or gate use of an episteme, use the direct episteme-use relation pattern.
7. If the phrase only names a relation position, field, parameter, or argument, use A.6.5.

#Conformance Checklist

#Common Anti-Patterns

#Consequences

#Rationale

Roles are needed because holons participate in different contexts without changing their substantial identity. A role value gives this context-local participation a name. The pump remains the same pump while being a cooling circulator in one context and test article in another. The engineer remains the same person while holding verifier or author roles in different work packages.

The selected ontology keeps three levels separate:

1. U.Role: the context-bound role value.
2. U.RoleAssignment: the typed relation value linking holder, role, context, and window.
3. Neighboring values: capability, method, method description, work plan, work occurrence, evidence-use relation, status-use relation, source-use relation, publication-use relation, and role description.

This is a compact architecture. It avoids type explosion, but it also avoids the opposite error of making role a generic slot word for anything that participates in anything else. A role is a real role value when an acting system or acting holon is being something in a bounded context. Other participation claims use their own relation patterns.

#SoTA-Echoing

#Relations

Builds on: A.1 for holon and system grounding; A.6.5 for SlotSpec discipline; E.24 for ontic and slot-relation discipline; A.6.RSIR for first-level wording-use recovery.

Governs with: A.2.1 for role assignment; A.2.2 for capability; A.2.5 for role state; A.2.7 for role relation structure and role-algebra lens boundary; A.15 for role-method-work alignment; Part F role-description and naming patterns for durable role names.

Keeps separate from: A.10, B.3, C.2.1, C.28, E.17, F.10, and direct evidence-use, status-use, source-use, publication-use, requirement-use, definition-use, explanation-use, assurance-use, and gate patterns for episteme use.

Precision-restoration applications: If source wording uses "role" for interface, signature, argument, field, parameter, capability, method, function, concern, interest, status, evidence, or publication, apply A.6.RSIR only until the governed object or claim kind is recovered, then apply the direct governing pattern.

#A.2:End

#U.RoleAssignment - Contextual Work-Role Assignment

Type: Definitional (D) Status: Stable Normativity: Normative unless marked informative

#Use This When

Plain name. Work-role assignment.

Use this pattern when a project must say which system, organization, person, team, service, agent, device, or other acting holon holds which U.Role in which bounded context, and when that assignment is current enough to admit, check, plan, or attribute work.

Typical moments:

• a work record says that "Alice reviewed", "Robot-7 inspected", "CI bot deployed", or "the operations team approved" and the role, holder, bounded context, or assignment window is missing;
• a method or method description names required roles, but the project has not linked those roles to concrete performers;
• a role state, capability requirement, separation-of-duties rule, or work gate depends on who holds the role now;
• an old source phrase gives an episteme an "evidence role", "standard role", "status role", or "requirement role" and the text must be repaired without making epistemes into work performers;
• a local notation such as Holder#Role:Context@Window is useful, but the notation must not replace the typed relation it abbreviates.

Primary EntityOfConcern. The EntityOfConcern is U.RoleAssignment: a typed work-facing assignment relation value. It links an admitted acting holder, a U.Role, a U.BoundedContext, and any assignment-currentness window or assignment source that is current for the claim.

Primary working reader. The first reader is an engineer-manager, analyst, or FPF author who needs work attribution, role admission, role-state checks, method requirements, or responsibility language to remain inspectable across contexts and editions.

First useful move. Recover the four core slots of the assignment relation: holder, role value, bounded context, and assignment window when current. Then recover any direct work-role qualifier, role-state admission, capability requirement, method requirement, work-plan relation, or work occurrence through its governing pattern.

What goes wrong if missed. Role labels float without holders or contexts. A method appears to have been enacted by a document. A work record names a person but not the role under which the work was admitted. A report or standard is treated as if it held a role because it is used as evidence or requirement source. The corpus then grows one role ontology for work and a second role ontology for epistemes.

What this buys. U.RoleAssignment gives one narrow relation for work-facing role holding. It keeps role values reusable, work attribution replayable, method requirements checkable, and episteme evidence or status uses outside the role-assignment relation.

Not this pattern when.

• If the current claim is the role value itself, role taxonomy, or role relation-neighborhood, use A.2.
• If the current claim is ability or operating envelope, use A.2.2.
• If the current claim is role state, role-state predicate, or enactable-state admission, use A.2.5.
• If the current claim is role-requirement substitution, incompatibility, qualification, or role bundle, use A.2.7.
• If the current claim is method, method description, work plan, performed work, or role-method-work alignment, use A.15 and the direct A.15 subpattern.
• If the current claim is evidence, source, standard, requirement, definition, explanation, publication, status, assurance, gate, or decision use of an episteme, use the direct pattern for that relation. Do not make the episteme a U.RoleAssignment holder.
• If "role" means a relation position, use A.6.5 SlotSpec discipline.

#Problem Frame

Work-facing roles are useful only after they are connected to concrete holders in a bounded context. "Reviewer", "operator", "deployer", "inspector", "authorizer", and "coordinator" are not enough by themselves. The project needs to know which holder bears the role, in which context, for which window or current claim, and under which neighboring role-state, capability, method, plan, and work relations.

The assignment relation must be narrow. It should not absorb capability, method, work, evidence, status, or publication use. A standard used as a requirement source can constrain work, but it does not hold a work-facing role. A report can be used as evidence, but it does not perform the review that produced it. A method description can require ReviewerRole, but the method description is not the reviewer.

A.2.1 therefore defines U.RoleAssignment as a typed relation value using A.6.5 SlotSpec discipline. The relation is work-facing: its holder is a U.System or acting holon admitted as system-like performer by the governing work or method pattern. Epistemes stay in evidence-use, status-use, source-use, publication-use, requirement-use, definition-use, explanation-use, assurance-use, gate-use, or decision-use relations.

#Problem

Without this pattern:

1. Role labels do not identify performers. Work records name a role-like word, but not the holder and context needed for attribution.
2. Assignment and role collapse. The role value, the holder, the bounded context, and the assignment window become one label.
3. Assignment and capability collapse. A role assignment is treated as evidence of ability, even though capability has its own envelope and evidence.
4. Assignment and method collapse. Holding a role is treated as if the holder automatically has a method or has already performed work.
5. Episteme-role drift returns. Standards, reports, datasets, definitions, requirements, and model cards are described as role holders instead of being related through evidence, status, source, publication, requirement, or assurance relations.
6. RoleEnactment becomes a second run-time object. A derived performed-by fact is mistaken for a durable U-kind beside U.Work.
7. Slot discipline is lost. Holder, role value, context, window, justification, provenance, and qualifier positions are not recoverable as distinct SlotKinds.

#Forces

#Solution

Use U.RoleAssignment for the typed relation that assigns a work-facing U.Role to an admitted acting holder in one bounded context.

RoleAssignmentCoreSlotSpec:
  HolderSlot:
  RoleValueSlot:
  BoundedContextSlot:
  AssignmentWindowSlot:
  AssignmentJustificationSlot:
  AssignmentProvenanceSlot:

This is a relation value. A record, registry row, publication, diagram, or file may describe, cite, or store the relation value. It is not the assignment itself by default.

#Core SlotSpecs

Direct work-role patterns may declare additional work-role qualifier SlotSpecs. Evidence-use and status-use relation slots are not assignment qualifiers unless a direct work-role pattern explicitly makes that work-role claim.

#Well-Formedness Constraints

Use these constraints as predicates over a filled assignment relation.

Invariant RA-S1 (Local role):
  RoleValueSlot content is a U.Role admitted in the BoundedContextSlot content.

Invariant RA-S2 (Holder admission):
  HolderSlot content is a U.System or an acting holon admitted as system-like performer by the governing work or method pattern.

Invariant RA-S3 (No role-as-holder):
  HolderSlot content is not U.Role and not U.RoleAssignment.

Invariant RA-S4 (No episteme holder by use):
  U.Episteme is not admitted as HolderSlot content merely because the episteme is used as evidence, source, standard, requirement, definition, explanation, publication, status bearer, or assurance input.

Invariant RA-S5 (Context locality):
  Cross-context assignment reuse requires a named bridge or direct context relation; shared labels do not create sameness.

Invariant RA-S6 (Window honesty):
  A claim that depends on current assignment validity names AssignmentWindowSlot content, inherits a declared bounded-context default, or states that the window is unknown, not recovered, not asserted, or blocking for the stronger claim.

Do not express these predicates with RFC-style deontics unless the sentence is imposing a duty on an author, validator, or published record.

#Open-World Slot Disposition

The SlotSpecs are a thinking discipline, not a demand to fill a form for every casual use.

Use these dispositions:

• filled: the relation instance names the slot filler or reference;
• inherited: the role definition or bounded-context rule fixes the value for the current claim;
• unknown or not recovered: the slot is relevant, but the project has not recovered it;
• not asserted: the text deliberately makes no claim about this slot;
• not current for this claim: the slot exists in the model, but the present claim does not depend on it;
• claim lowering or blocker: a stronger claim depends on the slot, so missing content lowers or blocks that claim.

For example, a quick staffing note may only need holder, role, and context. A safety-critical work attribution claim needs the assignment window, role-state admission, and method or work relation that the note omitted.

#Role State and Role-Description Characterization Hooks

U.RoleAssignment does not contain a role-state relation or a role-state description. The U.Role and its role description may be linked to:

• RoleCharacteristicSpace, the characteristic space used to describe role variants or role requirements in one bounded context;
• Role State Relation, the state-family relation used to decide whether a role assignment is in an enactable state;
• state assertions or evaluations governed by A.2.5 and the relevant evidence or evaluation pattern.

A work attribution claim may depend on those neighboring values. The assignment relation names the holder, role, context, and window; A.2.5 governs whether the assignment is in an enactable state for the current work.

#Role Assignment and Work

Work is not performed by the role value. Work is performed by the holder under a role assignment.

Use the direct relation:

Work.performedBy = RoleAssignment

Then check neighboring claims:

• the work occurrence is governed by [A.15.1](/generated/patterns/A.15.1);
• the selected method is governed by [A.3.1](/generated/patterns/A.3.1);
• the method description or required-role declaration is governed by [A.3.2](/generated/patterns/A.3.2) and [A.15](/generated/patterns/A.15);
• the work plan is governed by [A.15.2](/generated/patterns/A.15.2);
• role-state admission is governed by [A.2.5](/generated/patterns/A.2.5);
• capability is governed by [A.2.2](/generated/patterns/A.2.2).

A U.Work record may cite performedBy = some U.RoleAssignment. That citation does not make the work record the assignment and does not make the assignment a work occurrence.

#RoleEnactmentFact

Older FPF text used U.RoleEnactment. Current FPF treats role enactment as a derived relation or fact over U.Work and U.RoleAssignment, not as a durable U-kind.

Use this named fact only when a named relation is clearer than direct performedBy wording:

RoleEnactmentFact:
  workOccurrence: U.Work
  performedBy: U.RoleAssignment
  methodTrace?: U.Method or U.MethodDescription reference when current
  window?: inherited from work occurrence or role assignment when current

If a database, log, table, or publication stores a role-enactment entry, it stores a record of the fact unless a direct governing pattern admits record-as-value for that use.

#Episteme Evidence, Status, Source, and Publication Uses

Do not use U.RoleAssignment for an episteme merely because the episteme is useful in a project relation.

The repair is not to find a nicer role word. The repair is to recover the current relation and its slot fillers.

#Shorthand Notation

The compact notation is:

Holder#Role:Context@Window

Use it only as a readable notation for the typed assignment relation.

Examples:

• Robot_7#InspectorRole:MaintenanceLine_A@2026-06-15T09:00..2026-06-15T11:00
• OpsTeam#IncidentCommanderRole:PlantIncident_2026@open
• CI_Service#DeployerRole:ReleaseTrain_2026@2026-Q2

If the notation is missing the window, the current text must still say whether the window is inherited, unknown, not asserted, or not current for this claim when the claim depends on assignment currentness.

#Archetypal Grounding

#Industrial Inspection Work

A maintenance line assigns an inspection role to a robot for one shift.

Robot_7#InspectorRole:MaintenanceLine_A@2026-06-15T09:00..2026-06-15T11:00

The holder is a system. The role value is InspectorRole. The bounded context is MaintenanceLine_A. The assignment window covers the planned inspection shift.

This does not assert that the robot has the required sensor capability. Capability stays under [A.2.2](/generated/patterns/A.2.2). It does not assert that inspection work already occurred. Performed work stays under [A.15.1](/generated/patterns/A.15.1). It only gives later method, plan, role-state, and work-attribution claims a typed assignment relation to cite.

#Software Deployment

A release train has a deployment method description with a step requiring DeployerRole.

CI_Service#DeployerRole:ReleaseTrain_2026@2026-Q2
Work DeploymentRun_418 performedBy CI_Service#DeployerRole:ReleaseTrain_2026

The assignment relation admits a candidate performer. The work occurrence still needs the method or method-description relation, the assignment window, and any enactable role-state assertion required by [A.2.5](/generated/patterns/A.2.5). A green test suite, ticket approval, or policy rule may justify the assignment or the work gate, but those are neighboring evidence, gate, or policy relations, not hidden role values.

#Review Report and Reviewer

A human reviewer or review service can hold ReviewerRole in a review context. The review report produced by that work is an episteme.

Later, another team may use the report as evidence for a claim. That later relation is evidence-use around the report. The report does not hold ReviewerRole; the reviewer holder did.

#Standard Used in Safety Work

The source sentence "ISO 26262 has the normative standard role in this safety case" is repaired as a standard-use or requirement-use relation around an episteme. If a safety engineer performs work using that standard, the engineer or engineering team may hold a work-facing role assignment. The standard constrains, defines, or supplies source material; it does not perform work and does not become a holder in U.RoleAssignment.

#Bias Annotation

#Conformance Checklist

#Common Anti-Patterns and How to Avoid Them

#Consequences

A.2.1 makes work attribution and role admission replayable. A reader can ask: who is the holder, what role value is assigned, which bounded context gives that role meaning, and which window or source is current for the claim?

The benefit is compactness. FPF can keep one role-assignment relation for work-facing roles instead of multiplying role kinds for documents, standards, reports, dashboards, interfaces, method descriptions, and relation arguments.

The cost is discipline. Authors must recover neighboring claims instead of putting them into assignment prose. Capability, role state, method, work plan, performed work, evidence, status, publication, assurance, gate, and decision claims each keep their governing pattern.

Reopen A.2.1 only when the core assignment relation changes: admitted holder kinds, SlotSpecs, assignment-currentness discipline, direct work-role qualifiers, or the treatment of RoleEnactmentFact. Reopen neighboring patterns when the dispute is about capability, role state, method, work, evidence, status, source, publication, assurance, gate, or decision use.

#Rationale

The role ontologicalNeighborhood needs both role values and assignment relations. A.2 keeps U.Role as a compact context-bound value. A.2.1 gives that value a typed relation to a holder and context. A.15 then lets work cite the assignment.

The selected ontology prevents two common explosions. First, it prevents every context-local role from becoming a system subtype. Second, it prevents every evidence or status use of an episteme from becoming another role assignment.

The open-world slot model is deliberate. FPF should not require dummy windows or provenance entries for low-risk recognition text. It should also not permit stronger claims to rely on missing windows, missing role-state admission, or missing assignment source. The slot is considered when the claim needs it.

#SoTA-Echoing

#Relations

Builds on.

• A.1 and A.1.1 for holons, systems, and bounded contexts.
• A.2 for U.Role identity, taxonomy, and role relation-neighborhood.
• A.6.5 for SlotSpec discipline.

Coordinates with.

• A.2.2 for capability.
• A.2.5 for role state, role-state relation, role characterization, and enactable-state admission.
• A.2.7 for context-local role relation structure.
• A.15, A.15.1, and A.15.2 for method, work plan, work occurrence, and performed-by relation.
• A.3.1 and A.3.2 for method and method-description required-role relations.
• A.10, B.3, C.2.1, C.28, F.10, G.6, E.17, and E.10.D2 for evidence-use, status-use, source-use, publication-use, assurance, causal-use, and description-boundary cases that older text tried to express as episteme roles.

Does not replace.

• U.Work, U.Method, U.MethodDescription, U.WorkPlan, U.Capability, evidence relations, status assertions, gate decisions, commitments, permissions, or publication forms.
• A.6.5 relation-slot discipline. A.2.1 uses it for this assignment relation; it does not become a second slot discipline.

#A.2.1:End

#U.Capability - System Ability Envelope and Measures

Status: Stable

U.Capability is the FPF object for "can do within bounds".

Use this pattern when a project claim says that a person, team, machine, software service, organization, composite cell, or other system can produce a kind of result, perform a class of work, or meet a performance threshold. The claim is about ability, not about who is assigned, which method is described, which work occurred, or what was promised to another party.

Primary EntityOfConcern. The EntityOfConcern is U.Capability: a dispositional property of a U.System that states the system's ability to perform or produce a class of work results within a declared envelope and measured bounds.

Primary working reader. A manager, architect, engineer, safety assessor, scheduler, or model author who needs to decide whether a holder can be used for a work claim, method step, service promise, or architecture move without smuggling role assignment, method description, or past work into the ability claim.

First useful move. Ask: who is the holder system, what work family or result class is claimed, under what envelope, with what measures, during which qualification window, and by which current evidence or source-use relation?

What goes wrong if missed. A role label becomes a hidden proof of ability, a method description is treated as if it can perform work, a single successful run is generalized into a stable ability, or a promise is made without a measured capability behind it.

What this buys. Capability becomes checkable and reusable: a work-admission claim can test role assignment, role state, method requirements, and capability thresholds separately.

Not this pattern when.

• If the current claim is who holds a work-facing role in a bounded context, use A.2.1.
• If the current claim is whether that assignment is in an enactable state, use A.2.5.
• If the current claim is a role value, role description, role name, role relation structure, or role bundle, use A.2, Part F role patterns, or A.2.7.
• If the current claim is a way of doing, use A.3.1; if it is an episteme describing that way, use A.3.2.
• If the current claim is dated performed work or planned work, use A.15, A.15.1, or A.15.2.
• If the current claim is a promise to others, use the promise-content and commitment patterns.
• If the current claim is evidence, source, status, assurance, publication, or description use of an episteme, use the direct episteme-use pattern. Do not make the episteme a capability holder.

#Problem Frame

In ordinary work, the same sentence often carries several typed values:

• "The welding robot is the welder on this line."
• "The welding robot can weld seam type W at 12 seams per minute."
• "The welding procedure says how to weld seam type W."
• "The robot welded batch B at 10:20."
• "The supplier promises 12 seams per minute."

Only the second sentence is a U.Capability claim. The others may be role assignment, method description, performed work, or promise content. When FPF collapses them, project reasoning becomes brittle:

1. Role assignment becomes fake ability. "Assigned as verifier" is treated as "able to verify".
2. Method description becomes fake ability. A recipe or algorithm is treated as if it can execute itself.
3. Past work becomes fake ability. One successful work occurrence is treated as stable capacity.
4. Promise content becomes fake ability. A service promise hides the real system envelope and measured bounds.
5. Description becomes fake holder. A standard, report, model card, or dashboard is said to "have capability" because it is useful in a capability argument.
6. Unbounded ability becomes unreviewable. "Can machine titanium" does not name conditions, measures, version, calibration, or currentness.

#Kind and Boundary

U.Capability is a system-side ability claim.

Capability:
  CapabilityHolderRef: U.System
  WorkFamilyOrResultClassRef:
  CapabilityEnvelope:
  CapabilityMeasureSet:
  QualificationWindow:
  EvidenceOrSourceUseRefs:
  CapabilityCurrentnessPredicate:

CapabilityHolderRef. The holder is a U.System: a physical system, cyber system, socio-technical system, organization, team, composite cell, software service as deployed system, or other acting holon admitted as system for the claim. A role assignment, method, method description, work record, episteme, publication, standard, or dashboard is not the capability holder merely because it appears in the sentence.

WorkFamilyOrResultClassRef. The ability is about a class of work results or a method family the holder can enact. It may refer to a U.Method, U.MethodDescription, method family, result class, or work family, but the reference does not turn the method or description into the holder.

CapabilityEnvelope. The envelope states the bounded conditions under which the ability is claimed: input range, environment, resources, configuration, system version, calibration state, staffing composition, access constraints, safety limits, or other current conditions.

CapabilityMeasureSet. The measures state the achieved or required bounds with units, scales, tolerances, success predicates, reliability, throughput, latency, precision, defect rate, or other characteristics.

QualificationWindow. Capability is stable enough to plan with but not timeless. A claim may depend on software version, calibration horizon, team training state, wear, operating season, regulatory state, or other temporal currentness relation.

EvidenceOrSourceUseRefs. Evidence, tests, certifications, prior work summaries, simulations, audit records, standards, and model results can justify a capability claim through direct evidence or source-use relations. They do not become the capability.

CapabilityCurrentnessPredicate. The claim states what keeps the ability current and what lowers or reopens it.

Neighboring-term boundary. When a neighboring pattern uses U.WorkScope, recover the set-valued condition part of CapabilityEnvelope: the inputs, environment, resources, configuration, and assumptions against which an intended work slice is checked. When it uses U.WorkMeasures, recover CapabilityMeasureSet. JobSlice names the intended work slice for a work-admission check. QualificationWindow names the temporal currentness relation for the capability claim. These are neighboring governed terms, not substitute names for U.Capability.

#Positive Solution

Use U.Capability when the object under discussion is the holder's ability to achieve a result class within a declared envelope and measure set.

Minimal capability statement:

CapabilityStatement:
  holder: U.System
  canDo: WorkFamilyOrResultClass
  envelope: CapabilityEnvelope
  measures: CapabilityMeasureSet
  qualificationWindow: QualificationWindow
  evidenceOrSourceUse: EvidenceOrSourceUseRefs

Plain sentence form:

<System> can perform <work family or result class>
within <envelope>
at <measures>
during <qualification window>,
with <evidence or source-use relation>.

This form is deliberately not a method description. It does not list the step order or algorithm. It also does not assign the holder to a role or assert that a work occurrence happened.

#Separation From Neighboring Values

#Work-Admission Use

A method step or work claim may require both role and capability conditions.

WorkAdmissionCheck:
  roleAssignmentCurrent: A.2.1
  roleStateAdmitsWork: A.2.5
  methodStepRequires: A.3.1 or A.3.2
  holderCapabilityMeets: A.2.2
  performedWorkRecord: A.15.1 after execution

The checks are separate:

• role assignment says who is acting in which context;
• role state says whether that assignment is in a work-admitting state;
• method or method description says what capability threshold is required;
• capability says whether the holder can meet that threshold within the envelope and window;
• performed work says what actually happened.

Do not put the threshold into the role name. Do not treat a role assignment as proof of ability. Do not let a capability claim perform the work.

#Worked Cases

#Manufacturing Cell

RobotArm_A is assigned as WelderRole on AssemblyLine_2026. That assignment alone says who is eligible to act in the line context.

The capability claim is separate:

Capability:
  holder: RobotArm_A
  canDo: Weld_MIG_v3 seam family
  envelope: steel grades S235-S355, ambient 18-30 C, argon mix 92-95 percent, torch T-MIG-07
  measures: bead width 6.0 mm plus or minus 0.2 mm, throughput up to 12 seams per minute, defect rate below 0.5 percent
  qualificationWindow: calibration valid through 2026-09-30
  evidenceOrSourceUse: latest welding test report and calibration source relation

If a method step requires WelderRole and bead width tolerance below 0.2 mm, the role assignment and the capability are both checked. The assignment does not supply the tolerance, and the capability does not assign the robot to the shift.

#Software Service as Deployed System

PlannerService_v4 is a deployed system. It may have capability to generate job-shop schedules for 50-500 jobs and 5-40 machines, with benchmark optimality above 0.95 and latency below 20 ms in PlantScheduling_2026.

The algorithm paper and method description are not the capability. The deployed system has the capability only while its version, dependencies, input range, and operational measurements keep the claim current.

#Organization or Team

FinanceDept can close books for eight legal entities under IFRS with ERP v12, staffing at or above six qualified people, and close duration below five business days. That is a capability of the organizational system.

The monthly-close service promise is a promise content claim. The actual close for March 2026 is performed work. Staff assignments and role states are neighboring role claims. The capability claim keeps the ability of the department visible and measurable.

#Episteme Anti-Case

"ISO 26262 has safety capability" is not a capability claim. The standard is an episteme used as source, requirement, or assurance input. A safety engineering team or toolchain may have a capability to perform safety-case work using that standard within a declared envelope.

#Capability Currentness and Lowering

Lower or reopen a capability claim when any of these changes:

• the holder system changes composition, version, calibration, staffing, training state, toolchain, or environment;
• the envelope no longer covers the intended work slice;
• measures no longer meet the required threshold;
• the qualification window expires or becomes contested;
• evidence, source-use, test, audit, or simulation relations become stale or are reclassified;
• the method or method description changes the required capability threshold;
• the role assignment or role state changes, causing a work-admission claim to fail even though capability remains true;
• a composite holder changes dependency conditions.

Repair the smallest value that changed. A stale calibration window lowers the capability claim; it does not rewrite the role value. A failed role assignment lowers work admission; it does not by itself lower the holder's measured ability.

#Composite Capability

A composite system may have a capability that none of its parts has alone. Treat the composite as the holder.

Capability:
  holder: Cell_3
  canDo: place 12 PCB per minute
  envelope: feeder, vision, head, controller, and operator conditions
  measures: placement tolerance, throughput, fault rate
  qualificationWindow: current configuration and calibration window
  dependencyNotes: feeder and vision subsystem conditions

The capability belongs to Cell_3, not to every part and not to the method description. Dependencies may be named, but the whole-system capability remains a property of the composite holder.

#Checklist

#Anti-Patterns and Repairs

#Consequences

Benefits.

• Planning separates "can do" from "is assigned now".
• Method steps can name capability thresholds without putting extra meaning into role names.
• Work records can be judged against the capability claim current at the time of work.
• Promise content becomes less magical because the internal ability and measured envelope are explicit.
• Composite-system ability can be stated at the right holder instead of scattered across parts.

Costs.

• Capability tables need envelope, measures, and currentness fields.
• Teams need to stop using role labels as shortcuts for ability.
• Some old "function", "service", "process", and "algorithm" sentences need kind recovery before they can be used in FPF.

The cost is intentional: without it, FPF cannot distinguish authorization, ability, method, and performance.

#SoTA-Echoing

Source-currentness note: DoDAF and TOGAF are used here as stable capability-planning practice lineage, not as the full current frontier. Current pressure comes from SysML v2 and 2025-2026 MBSE work on semantic precision, uncertainty, stakeholder-context formalization, and model integration. The NIST zero-trust line is used only for the split between current authorization and measured ability.

#Relations

#Excluded Objects

Do not use U.Capability as the current object for:

• role value, role assignment, role state, role relation structure, or role description;
• method, method family, method description, or algorithm description;
• work plan, work occurrence, run record, or measurement trace;
• evidence graph, source record, model card, standard, report, dashboard, publication, or specification-use relation;
• promise content, commitment, permission, authority relation, or policy decision;
• structural part, module, interface, port, or functional structure unless the current claim is the ability of a holder system expressed through that structure.

These values may be related to a capability claim. They do not become the capability by adjacency.

#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 classification of “contract / SLA / guarantee” language is handled by A.6.C, which applies 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 or 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 lexical 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, and so on) or to the correct underlying EntityOfConcern or project-side FPF kind (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 or 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, or composite), not a U.Work episode and not an extensional delivered-result referent.
• 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 lexical 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?: {
    entityOfConcernRef?: 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 records. 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 or U.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 or 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 or 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 -->|"access used in"| 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 a bundle of commitments, evidence specs, and publication carriers.

• 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.entityOfConcernRef (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 or 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 or U.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 or obtain service delivery work through a request‑facing interface, accessSpec MUST reference the MethodDescription that defines eligibility and access-use rules (API, desk, or 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-result referent.

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, or 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, result facet, or both); 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 uses the service access specification to request or obtain delivery work (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 or U.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 and evidence (C.16/C.25) and pin {UnitType, ScaleKind, ReferencePlane, EditionId}. → For each promise content, define 2–4 KPIs and the Work-based formulas named by value , 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

#Episteme Evidence-Use and Status-Use Relations

Type: Boundary and relation-use pattern Status: Stable Normativity: Normative

#Problem Frame

Use this pattern when a report, proof, dataset, measurement file, standard, requirement, dashboard cell, model card, publication face, generated explanation, or other U.Episteme is being used as evidence, source, status bearer, assurance input, or causal-use input for a claim.

Use it when the working question is:

• which episteme is being used;
• which claim, theory statement, status assertion, use, or causal-use question the episteme is being used for;
• which bounded context, claim scope, grounding holon, polarity, relevance window, assurance use, weight model, and provenance constraints are current;
• whether old source wording such as "evidence role", "status role", "standard role", or "the report plays a role" hides an evidence-use, status-use, source-use, publication-use, assurance-use, gate-use, or causal-use relation;
• whether the evidence-use or status-use relation is sufficiently specified for the intended reliance, or only enough for orientation, source-finding, a reversible probe, or a narrowed use.

Primary EntityOfConcern. The EntityOfConcern is the evidence-use relation or status-use relation around an episteme. It is not U.Role, not U.RoleAssignment, and not a system performing work.

First useful move. Name the episteme, the bounded context, the claim or status being addressed, and the direct governing pattern that owns the use: usually A.10, B.3, C.2.1, C.28, F.10, G.6, E.17, E.10.D2, or a direct gate, source, requirement, definition, explanation, or publication-use pattern.

What goes wrong if missed. A document starts acting like an agent, a dataset is treated as if it held a work-facing role, a dashboard status becomes permission, a proof becomes global evidence without a theory fence, or a simulation-only counterfactual output is relabelled as realized causal evidence.

What this buys. The project can use epistemes as evidence, status bearers, sources, standards, requirements, definitions, explanations, publications, or assurance inputs without creating a second role ontology for epistemes and without losing claim scope, polarity, freshness, provenance, or assurance-use distinctions.

Not this pattern when. If the current claim is a system or acting holon holding a work-facing role, use A.2 and A.2.1. If the current claim is performed work, use A.15.1. If the current claim is the full evidence-provenance graph relation, use A.10. If the current claim is assurance, use B.3. If the current claim is causal use, use C.28. If the current claim is a status family or status mapping, use F.10. If the current claim is publication-use or source-use, use E.17 and E.10.D2 as needed.

#Problem

Older FPF text used U.EvidenceRole for a useful need but chose the wrong ontology. The need was real: an episteme can be used as evidence for a claim inside a bounded context, with scope, polarity, time, assurance use, weight, and provenance constraints. The error was to model that use as a non-behavioral role held by the episteme through U.RoleAssignment.

That creates several failures:

1. Episteme-as-holder drift. A paper, proof, dataset, standard, or dashboard cell is treated as if it held a work-facing role.
2. Evidence role ontology drift. ModelFitEvidenceRole, MeasurementEvidenceRole, or AxiomaticProofRole look like role kinds instead of evidence-use relation classifications or local evidence-use labels.
3. Claim relation collapse. Target claim, grounding holon, claim scope, polarity, relevance window, assurance use, weight model, and provenance constraints are hidden behind one role name.
4. Evidence and status collapse. A status badge, standard reference, approval-looking display, publication face, or requirement source is treated as evidence, status assertion, gate passage, permission, and assurance at once.
5. Work confusion. The work that produced an episteme and the later use of that episteme as evidence are folded into one relation.
6. Causal-use laundering. Observational association, intervention, realized counterfactual sample, identified counterfactual estimate, and simulation-only output are relabelled by evidence-wording instead of being governed by C.28.
7. Cross-context leakage. Evidence accepted in one context is reused in another without an explicit bridge, source-currentness relation, or assurance-use statement.

#Forces

#Solution

Do not create or use U.EvidenceRole as a durable role kind. Do not place an episteme in U.RoleAssignment merely because it is used as evidence, source, standard, requirement, definition, explanation, publication, status bearer, or assurance input.

Use direct relation patterns instead:

#Evidence-Use Relation Slots

An evidence-use relation is a relation around an episteme and a claim or effect. It is not a role assignment.

These SlotKinds are evidence-use relation positions. They are not work-role qualifier slots, not U.Role names, and not new U-kinds by themselves.

#Status-Use Relation Slots

A status-use relation is a relation around a bearer, status value, scope, window, source, and use. It is not a status role held by an episteme.

These names do not create a generic status ontic. They are repair vocabulary for status-use relations in the current role and relation-slot settlement. Durable status families remain governed by F.10 or a direct status pattern.

#Minimal Evidence-Use Statement

For ordinary use, write only the fields needed for the current reliance question:

Episteme evidence-use statement:
  EvidenceEpisteme:
  BoundedContext:
  EvidenceTargetClaim:
  EvidenceClaimGroundingHolon:
  EvidenceClaimScope:
  EvidencePolarity:
  EvidenceRelevanceWindow:
  EvidenceAssuranceUse:
  EvidenceWeightModel:
  EvidenceProvenanceConstraint:
  DirectGoverningPattern:
  UnsupportedOverread:

UnsupportedOverread names the stronger claim not carried by this relation, such as approval, permission, gate passage, performed work, assurance, causal identification, release confidence, or global truth.

#Minimal Status-Use Statement

For status-like cases, write the smallest relation that keeps status from becoming role assignment, gate passage, or assurance by display alone:

Episteme status-use statement:
  StatusBearer:
  StatusTarget:
  StatusScope:
  StatusValue:
  StatusWindow:
  StatusUse:
  StatusProvenanceConstraint:
  DirectGoverningPattern:
  UnsupportedOverread:

If the status is used for a gate, release, work-plan readiness, assurance, or admission decision, apply the direct governing pattern for that use. A.2.4 only keeps the status-use relation typed and prevents old role-holder grammar from returning.

#Formal, Empirical, and Causal Evidence Uses

Older labels such as AxiomaticProofRole, ObservationEvidenceRole, MeasurementEvidenceRole, ModelFitEvidenceRole, ReplicationEvidenceRole, CalibrationEvidenceRole, and BenchmarkEvidenceRole become evidence-use classifications or local evidence-use labels, not U.Role values.

Formal line:

• the evidence episteme is a proof, derivation, counterexample, theory note, proof-check result, or formal publication;
• EvidenceTargetClaimSlot names the theorem or theory statement;
• EvidenceClaimScopeSlot names the theory domain or declared scope;
• EvidenceRelevanceWindowSlot usually names a theory-version fence rather than an empirical expiry date;
• EvidenceProvenanceConstraintSlot names proof checks, source publications, theory version, and dependency conditions when current.

Empirical line:

• the evidence episteme is a dataset, observation record, measurement report, replication report, calibration result, benchmark result, model-fit report, or similar episteme;
• EvidenceClaimScopeSlot, EvidenceRelevanceWindowSlot, EvidenceWeightModelSlot, and EvidenceProvenanceConstraintSlot usually decide whether the use is admissible;
• the producing work remains U.Work under A.15.1, performed by a system or acting holon under U.RoleAssignment where that trace is current.

Causal-use line:

• the causal-use question belongs to C.28;
• A.2.4 keeps the evidence-use relation typed so the episteme is not relabelled by vocabulary alone;
• exact C.28 values such as observationalAssociationSupportBasis, interventionalActionSupportBasis, realizedCounterfactualSampleSupportBasis, identifiedCounterfactualEstimateSupportBasis, and simulationOnlyCounterfactualOutputBasis remain C.28 values, not role names.

#Work, Source, and Publication Boundary

The producing work and the later evidence use are different relations.

• A lab run, proof-checking session, calibration run, benchmark run, review, model evaluation, or data extraction can be U.Work.
• The report, proof file, dataset, benchmark table, or publication produced by that work can be a U.Episteme.
• A later project can use that episteme as evidence through an evidence-use relation.
• A publication face, view, source citation, credential view, dashboard display, or generated explanation can cue evidence or status use, but it does not become the evidence-use relation by itself.

When the source-currentness, publication-use, view, explanation, or specification-use question is current, use E.17, E.17.0, E.17.2, E.17.EFP, E.10.D2, A.10, or the direct source-use pattern before relying on the evidence-use or status-use relation.

#Shortcut Cost and Reopen Condition

The baseline is the direct governing pattern: full A.10 for evidence-provenance graph relations, full B.3 for assurance, full C.28 for causal use, full F.10 for status families, full E.17 or E.10.D2 for publication-use and description-use cases, and full A.15.1 when the producing work is current.

A.2.4 is the weaker first-use representation. It saves effort by writing only the relation positions needed to stop old role wording from collapsing evidence, status, work, assurance, source, and publication claims. The loss budget is narrow: A.2.4 may name the evidence-use or status-use relation, preserve the named direct governing pattern, and state unsupported overread. It may not decide assurance value, gate passage, causal identification, source-currentness order, publication interpretation, or performed-work truth.

Open the direct governing pattern when the attempted use depends on assurance, safety, release, compliance, causal effect, gate decision, permission, performed work, source freshness, publication use, status currentness, or a contested provenance relation.

#Archetypal Grounding

#Proof Used as Evidence

Lemma-12.proof is an episteme used as evidence for Theorem-12 in GraphTheory_v3.1.

The evidence-use relation names:

• EvidenceEpistemeSlot = Lemma-12.proof;
• EvidenceTargetClaimSlot = Theorem-12;
• EvidenceClaimScopeSlot = finite DAGs inside GraphTheory_v3.1;
• EvidencePolaritySlot = supports or an entailment-specific polarity when the local value set declares one;
• EvidenceRelevanceWindowSlot = theory-version fence GraphTheory_v3.1;
• EvidenceAssuranceUseSlot = verification use;
• EvidenceProvenanceConstraintSlot = proof publication, proof-check result, dependency list, and theory version.

No episteme holds AxiomaticProofRole. The proof episteme is used in a claim-bound evidence-use relation.

#Calibration Dataset Used as Evidence

Trial-R3.csv is an episteme used as evidence for Sensor S accuracy +/-0.3 C in [0,70] C under lab conditions L.

The evidence-use relation names the claim scope, polarity, relevance window, weight model, producing work runs, method description, measurement traceability, and freshness policy. If a later assurance claim is made, B.3 consumes this relation. If the calibration run itself is being discussed, use A.15.1 for the work occurrence.

#Dashboard Status Cell

A release dashboard shows Ready.

That visible cell can be:

• a status cue;
• a status assertion if the source, status value, scope, window, and provenance constraints are recoverable;
• evidence for a gate or release claim only when A.10 and the gate pattern recover the source relation;
• no evidence-use relation if it is stale, copied, unauthenticated, or disconnected from the decision source.

It is not a status role held by the dashboard episteme.

#Standard Used as Requirement or Evidence

An ISO/IEC/IEEE standard clause can be an episteme used as a requirement source, definition source, status source, or evidence source depending on the current claim.

Do not write "the standard has a normative role" as live FPF ontology. Recover the relation governed by the current claim: standard-use, requirement-use, definition-use, source-use, evidence-use, status-use, or assurance-use.

#Simulation-Only Counterfactual Output

A simulation output mentions a counterfactual. That output may be an episteme used in an evidence-use relation. The causal-use class still belongs to C.28.

If the current C.28 value is simulationOnlyCounterfactualOutputBasis, the evidence-use relation cannot be relabelled as realizedCounterfactualSampleSupportBasis or interventionalActionSupportBasis by evidence wording, validation wording, or role wording alone.

#Bias Annotation

This pattern mainly blocks six biases:

• episteme-as-role-holder bias: an episteme is placed in U.RoleAssignment because it is useful as evidence or status;
• evidence-name-as-kind bias: local evidence-use labels become U.Role names;
• status-display-as-authority bias: a visible badge or status cell becomes gate passage, permission, or assurance;
• work-as-evidence-use collapse: producing work, produced episteme, and later evidence use are treated as one relation;
• scope-free evidence bias: target claim, grounding holon, claim scope, polarity, time, assurance use, or provenance constraints are omitted;
• causal laundering bias: causal evidence classes are changed by source vocabulary rather than by C.28 causal-use reasoning.

The repair is to recover the episteme first, then recover the evidence-use, status-use, source-use, publication-use, assurance-use, or causal-use relation that is current.

#Conformance Checklist

#Anti-Patterns and Repairs

#Consequences

The positive consequence is a simpler role ontology. Systems and acting holons hold work-facing roles; epistemes are used through evidence-use, status-use, source-use, publication-use, requirement-use, definition-use, explanation-use, assurance-use, and causal-use relations.

The cost is explicit relation recovery. A phrase such as "evidence role", "status role", "standard role", "proof role", or "benchmark role" no longer closes the claim. The user needs to recover which episteme, claim, scope, status, time window, provenance constraint, and direct pattern are current.

The payoff is that one episteme can be reused honestly across many claims. Each use can have a different target claim, grounding holon, scope, polarity, relevance window, assurance use, weight model, or provenance constraint without multiplying role kinds.

#Rationale and SoTA-Echoing

Refresh this pattern's source use when those provenance, credential, attestation, assurance, causal-use, or foundational-ontology practices change the separation between evidence presence, status display, assurance, provenance, causal class, and role assignment.

#Relations

• Builds on: A.2 for U.Role, A.2.1 for U.RoleAssignment, A.6.5 for SlotSpec discipline, and C.2.1 for episteme slot relation and episteme identity.
• Coordinates with: A.10 for evidence-provenance graph relation; B.3 for assurance; C.28 for causal-use evidence classes; F.10 for status families; G.6 for evidence graph and provenance ledgers; E.17, E.17.0, E.17.2, and E.17.EFP for publication, view, and explanation-use cases; E.10.D2 for EntityOfConcern, description episteme, and specification-use discipline.
• Separates from: A.15.1 for producing work; A.15.2 for planned work; gate patterns for gate passage; A.2.8 and A.2.9 for commitments and speech acts; source-currentness patterns for source freshness and source order.
• Feeds: A.6.RSIR and E.10.ARCH as the current repair target when source wording says "evidence role", "status role", "standard role", or another role-shaped phrase around an episteme.

#Lowering, Repair, and Refresh

Lower an attempted A.2.4 use when the episteme is known but the target claim, scope, polarity, status value, time window, or provenance constraints are not recoverable. The lowered result may be source-finding, orientation, an evidence-needed note, a status-source request, or a narrowed reliance use.

Repair the use when a neighboring relation is actually current: performed work, assurance, causal use, gate passage, permission, commitment, publication-use, source-currentness, requirement-use, definition-use, or explanation-use.

Refresh the use when the episteme edition, target claim, grounding holon, claim scope, theory version, relevance window, source-currentness relation, status source, proof check, measurement trace, method description, or assurance-use relation changes.

#A.2.4:End

#RoleStateRelation@BoundedContext - Role State Space and Enactable-State Admission

Type: Definitional (D) Status: Stable Normativity: Normative unless marked informative

#Use This When

Plain name. Role-state space.

Use this pattern when a project needs to decide whether a role assignment is currently in a state that admits a work claim, a method-step claim, an incompatibility claim, or a role-readiness claim.

Typical moments:

• a work record says that a person, team, device, service, agent, or machine acted as technical checker, operator, deployer, verifier, surgeon, sensor, or incident commander, but the current role state is unclear;
• a method description names a required role, and the project needs to state which role states admit the step;
• a role assignment is current, but the holder may be suspended, stale, uncalibrated, fatigued, not yet authorized, or otherwise not in an enactable state;
• a role-relation claim such as role-requirement substitution, incompatibility, or bundle expression depends on role states rather than labels alone;
• a source says "ready", "approved", "validated", "authorized", "active", "stale", or "blocked" and it is unclear whether this is a role state, an evidence or status relation around an episteme, an admission result, a capability value, or a work occurrence.

Primary EntityOfConcern. The EntityOfConcern is RoleStateRelation@BoundedContext: the selected context-local state-space relation for one U.Role in one U.BoundedContext. It names role states, state predicates, state-change predicates when current, and the subset of states that admit work through a U.RoleAssignment. It is a real FPF object, but it is not a new U.* kind beside U.Role; its identity is carried by the role value, bounded context, state set, state predicates, and work-admission relation.

Primary working reader. The first reader is an engineer-manager, analyst, safety checker, operations lead, or FPF author who needs to keep role assignment, role state, holder capability, method requirement, and performed work distinct while still deciding whether a work claim may proceed.

First useful move. Name the role and bounded context, list the states that matter for the current claim, mark which states admit work, and state what observation, evaluation, speech act, work record, or source relation can justify a StateAssertion for the relevant window.

What goes wrong if missed. A role label becomes a permission slip. A role assignment is treated as ability. A certificate, report, standard, status marker, or dashboard is treated as if it held a work-facing role. Separation-of-duties checks operate on labels instead of states. Old source phrases such as "approved evidence role" or unlabeled readiness marks create a second role ontology.

What this buys. Role admission becomes inspectable without making forms heavy. The same role value can have different current states in different contexts and windows; method and work claims can ask only for the state evidence they need; episteme evidence and status uses stay with their direct patterns.

Not this pattern when.

• If the current claim is the role value itself, use A.2.
• If the current claim is the assignment relation linking holder, role, bounded context, and assignment window, use A.2.1.
• If the current claim is ability or operating envelope, use A.2.2.
• If the current claim is role-requirement substitution, incompatibility, or bundle expression independent of current state, use A.2.7.
• If the current claim is selected method, method description, work plan, or performed work, use A.15 and the direct A.15 subpattern.
• If the current claim is an episteme used as evidence, source, standard, requirement, definition, explanation, publication, status bearer, assurance input, or admission input, use the direct pattern for that relation. Do not turn the episteme into a role holder or role state.

#Problem Frame

Work-facing role assignment is not enough for safe work attribution. "Dana holds IncidentCommanderRole" may be true while Dana is off-duty, conflicted by another role assignment, outside the current assignment window, or missing a fresh authorization source. "Robot-7 holds InspectorRole" may be true while the robot is uncalibrated. "Thermometer T-17 holds ObserverRole" may be true while the calibration evidence is stale.

The project needs a small state space for each important role in each bounded context. That state space says which role states exist, which state predicates justify them, and which states admit work. It is not a method order, not a task list, not a capability, not a work log, and not an episteme status ontology.

A.2.5 therefore defines RoleStateRelation@BoundedContext as a selected relation structure around a U.Role and bounded context. It uses state-machine or graph notation only as a selected mathematical or representation lens where helpful. The FPF object is the role-state relation used for work admission and role-state claims.

#Problem

Without this pattern:

1. Assignment and state collapse. A holder assigned to a role is treated as currently ready.
2. Role and capability collapse. A state label such as "ready" is treated as ability instead of a window-bounded state assertion.
3. Role state and work collapse. Being in a state is mistaken for having performed the work.
4. State and source collapse. A certificate, report, standard, model card, dashboard, or publication is treated as the state itself rather than as a source or evidence relation for a state assertion.
5. Label-only incompatibility appears. Incompatibility checks block or admit work by role names rather than by enactable states in a window.
6. Context drift returns. "Approved" or "Ready" travels across contexts without named state predicates or loss.
7. Old enactment ontology survives. RoleEnactment becomes a durable root value even though performed work is governed by U.Work and U.RoleAssignment.

#Forces

#Solution

Use RoleStateRelation@BoundedContext for the state-space relation of one U.Role in one U.BoundedContext.

RoleStateRelation:
  RoleValueRef:
  BoundedContextRef:
  RoleStateSet:
  EnactableStateSet:
  StatePredicateSet:
  StateChangePredicateSet:
  StateAssertionRelation:
  RoleRelationStructureHooks:
  UKindDisposition: non-U selected relation structure

This is a relation value. A role description, policy, register, diagram, checklist, or publication may describe or store the relation value. The description or register is not the role-state relation itself by default.

Do not promote this object to a separate U.* kind. RoleStateRelation@BoundedContext has action-facing use because it controls role-state admission, but the identity is reducible to slot and relation combinatorics over existing governed values: U.Role, U.BoundedContext, role-state values, state predicates, state assertions, and the work-admission relation through U.RoleAssignment. The durable U-kind remains U.Role; A.2.5 supplies the selected state relation inside the role ontologicalNeighborhood.

#Core SlotSpecs

The SlotSpecs are open-world. A casual role-state note may only name role, context, and a state. A safety-critical work claim may require state predicates, evidence, assignment window, role-state window, capability checks, and method-step relation. Missing relevant content lowers or blocks the stronger claim; it does not assert that the value cannot exist.

#State and State Assertion

Role state. A role state is a context-local value in the RoleStateSet for one U.Role and one bounded context. Names such as Ready, Calibrated, Suspended, Authorized, Stale, or Blocked are local labels until their predicates are named.

Enactable state. An enactable state is a role state admitted by EnactableStateSet. A method-step claim or work-attribution claim that requires the role can use that state only with a current StateAssertion.

State assertion. A StateAssertion says that one U.RoleAssignment is in one role state for one window, with named evidence or source relations.

StateAssertion:
  RoleAssignmentRef:
  RoleStateRef:
  AssertionWindow:
  PredicateEvaluation:
  EvidenceOrSourceUseRefs:
  AssertionStatus:

PredicateEvaluation is governed by the evaluation or evidence pattern that owns the claim. The assertion does not make the evidence episteme a role holder.

#Enactable-State Admission

Use this admission predicate when a method or work claim depends on role state:

EnactableStateAdmission:
  requiredRole: U.Role
  roleAssignment: U.RoleAssignment
  requiredContext: U.BoundedContext
  workOrMethodClaim:
  window:
  admitted iff StateAssertion(roleAssignment, state, window)
              and state is in EnactableStateSet(requiredRole, requiredContext)

This predicate admits or blocks the work or method-step claim. It does not create work, select a method, grant capability, or prove that work occurred.

#State Predicates and State-Change Predicates

State predicates answer: is this assignment in this state for this window?

Examples:

• CalibrationAge <= 30 days;
• AuthorizationDecision exists within the stated window;
• FatigueScore below threshold;
• IndependenceFrom(holder, conflictingAssignment) is true;
• ObservationProcedureActive and calibration trace is current;
• NoOpenIncident above declared severity.

State-change predicates answer: what evidence or event changes the state relation? They may reuse the same observations or decisions, but their use is different. A predicate that says calibration expired can justify a Stale state assertion; it still does not prescribe the method order for recalibration work.

#Role Relation Structure Hooks

When A.2.7 declares role-requirement substitution, incompatibility, or bundle expressions, A.2.5 adds state-sensitive admission.

Do not construct product state spaces by default. Product states are admitted only when the bounded context actually maintains a composite role value and gives it its own RoleStateRelation@BoundedContext. A graph or state-machine diagram may describe that relation; it is not the relation in life.

#Separation From Capability, Method, Work, Evidence, and Status

#Worked Slices

#Incident Commander

Context: SRE_Prod_Cluster_EU_2026.

Role: IncidentCommanderRole.

States:

• OffDuty - not in the on-call assignment window;
• OnCall - assignment window and contact source are current;
• Authorized - escalation decision source is current;
• Ready - on call, authorized, not conflicted, attention-pressure indicator below threshold;
• RunningIncident - currently performing incident-command work;
• Blocked - conflicting assignment or missing source.

Ready and RunningIncident are enactable states for incident-command work in this context. A work record for "Declare severity level" may cite performedBy = Dana#IncidentCommanderRole:SRE_Prod_Cluster_EU_2026, but the work claim is admitted only when a StateAssertion puts that assignment in Ready or RunningIncident for the declaration window.

#Thermometer Observer

Context: Metrology_Thermo_2026.

Role: ThermometerObserverRole.

States:

• Unqualified - no traceable calibration source;
• Calibrated - calibration source current;
• Synchronized - time relation within threshold;
• InRange - drift and environment predicates hold;
• Measuring - observation procedure is active;
• Stale - calibration or synchronization window expired;
• Quarantined - suspected contamination or bias.

Measuring is the only enactable state for the "record temperature" work claim. Calibrated and Synchronized are useful role states, but they do not by themselves admit observation work.

#Standard or Dataset With "Status Role" Source Wording

A source may say that a standard has an "approved role" or a dataset has an "evidence role." Do not make a RoleStateRelation@BoundedContext for the episteme unless a direct work-facing role is actually current. Usually the repair is:

• standard or requirement source: requirement-use, status-use, source-use, or publication-use relation;
• dataset or report: evidence-use, source-use, measurement, benchmark, freshness, or provenance relation;
• claim about the worker who approved, measured, verified, or published it: U.Work performed by a holder under U.RoleAssignment, with A.2.5 used only for that holder's role state.

#Archetypal Grounding

System side. A role-state relation can govern a person, team, machine, service, software agent, laboratory instrument, organization, or other acting holon through U.RoleAssignment. The holder is still governed by A.2.1; capability by A.2.2; performed work by A.15.1.

Episteme side. A role-state relation may be described by an episteme, and evidence for a state assertion may be an episteme. That does not make the episteme a role holder. If the EntityOfConcern is a report, standard, dataset, requirement, proof, model card, or publication, the current relation is usually evidence-use, status-use, source-use, requirement-use, definition-use, explanation-use, publication-use, assurance-use, or admission-use.

#Bias Annotation

This pattern resists four common biases:

• status-word bias: treating Approved, Ready, or Validated as self-explanatory instead of context-local state predicates;
• role-label bias: treating a role assignment as current ability or performed work;
• semio-bias: making the pattern about records, certificates, diagrams, or publications rather than the role-state relation they describe or evidence;
• IT-bias: reducing role states to access-control states for software users. Software access is one case; the same ontology applies to surgery, metrology, plant operations, teams, AI agents, and organizations.

#Conformance Checklist

#Common Anti-Patterns and How to Avoid Them

#Consequences

Good consequences:

• work admission becomes reviewable without making every role assignment a large form;
• role relation structure can use current state rather than labels alone;
• role descriptions can publish state predicates without turning descriptions into states;
• evidence and status around epistemes no longer create shadow role kinds;
• cross-context role-state comparison becomes explicit rather than label-based.

Costs:

• high-consequence work needs state predicates and currentness windows;
• projects need to decide which role states actually admit work;
• role-state design can become too detailed if authors encode method order instead of admission predicates;
• cross-context reuse needs explicit mapping or comparison when state predicates differ.

#Lowering and Reopen Conditions

Lower a role-state claim or reopen A.2.5 when any of these changes:

• the role assignment, assignment window, or bounded context changes;
• the state predicates, state-change predicates, or enactable-state set change;
• a StateAssertion window expires, is contested, or loses the evidence or source relation that made it current;
• a method description changes its required roles or required role states;
• a capability claim changes the holder envelope needed by a state predicate;
• a role-relation structure changes role-requirement substitution, incompatibility, or bundle admission;
• an episteme previously used as evidence, source, standard, requirement, publication, or status value is reclassified by its direct pattern.

The smallest repair is normally local: update the state predicate, state assertion, window, role-relation-structure hook, or neighboring capability, method, work, evidence, or status relation that changed. Do not rewrite the whole role value or role assignment when only one role-state claim changed.

#Rationale

FPF keeps role state separate because the surrounding values have different kinds and different failure modes. A role assignment can be valid while the role state is not work-admitting. A holder can be capable while the assignment window is stale. A method can require a role while no current holder has an enactable state. A publication can describe or evidence any of these without becoming the holder, the role, or the state.

The state-machine lens is useful because finite named states, guarded change, and state assertions are easy to inspect. But the pattern does not make every role claim executable behavior. It uses the state lens only where the project needs role-state recognition, admission, currentness, and state-aware role relation structure.

#SoTA-Echoing

#Relations

#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, and 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, and 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 specification, model, safety case, or operational-playbook publication 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.

#Forces

#Solution — Overview (preview; full definitions in Part 2)

USM introduces:

• U.ContextSlice — an addressable slice of a bounded context (terminology, parameter ranges, versions/Standards, and a mandatory Γ_time selector). All scope checks are performed on slices.
• U.Scope — the abstract set‑valued scope object over U.ContextSlice.
• Specializations: U.ClaimScope (nick G) on U.Episteme (“where the claim holds”), U.WorkScope on U.Capability (“where the capability can deliver Work at declared measures within qualification windows”), and U.PublicationScope on publication carriers (“where the publication surface is admissible”).
• One algebra: serial intersection, parallel SpanUnion (only where independently supported), translate via Bridge (CL affects R, not F/G), and widen / narrow / refit operations for scope evolution.

Lexical commitments (normative): — In normative text and guards, use Claim scope (G), Work scope, and Publication scope. — Do not name the scope object “applicability/envelope/generality/capability envelope/publication applicability/validity.” Those words are permitted only as explanatory aliases in notes.

#Normative Definitions

#USM as a U.Mechanism.Intension (normalization for A.6.1/A.6.5)

Intent. This subsection makes the USM definition in A.2.6 explicitly conform to the U.Mechanism intension requirements (A.6.1) and the …Slot / …Ref lexical discipline (A.6.5), without changing USM’s meaning.

USM Mechanism.Intension (normative; A.6.1 decomposition).

• Imports (USM). U.ContextSlice, U.ContextSliceSet, Part B Bridge/CL (U.Bridge, U.CongruenceLevel), and U.GammaTimePolicy.
• BaseType (USM). U.ContextSliceSet (set‑valued scope objects range over sets of addressable U.ContextSlice).
• SliceSet (USM). U.ContextSliceSet (addressable U.ContextSlices; see §6.1).
• SubjectKind (USM). U.Scope with kind specialisations: U.ClaimScope ⊑ U.Scope, U.WorkScope ⊑ U.Scope, U.PublicationScope ⊑ U.Scope.
• ExtentRule (USM). The quantifier domain is the set of well‑formed scope objects over the SliceSet: Extension(U.Scope, slice) = { S | S ⊆ U.ContextSliceSet }.
• ResultKind? (USM). U.Scope (for operators that return scopes, e.g., ∩, SpanUnion, translate).

SlotIndex (USM) for operators/guards (normative; A.6.0:4.1.1 + A.6.5). These SlotKinds are stable names for signatures, substitution laws, and guard templates; they are not additional data slots on carriers.

OperationAlgebra (USM) with SlotSpecs (normative).

• member(SliceSlot, ScopeSlot) — notation form: SliceSlot ∈ ScopeSlot.
• subset(LeftScopeSlot, RightScopeSlot) — notation form: LeftScopeSlot ⊆ RightScopeSlot.
• intersect(LeftScopeSlot, RightScopeSlot) → U.Scope — notation form: LeftScopeSlot ∩ RightScopeSlot.
• spanUnion(ScopeFamilySlot) → U.Scope — notation form: SpanUnion(ScopeFamilySlot).
• translate(BridgeRef, ScopeSlot) → U.Scope — Cross‑context mapping via Bridge.
• widen(LeftScopeSlot, RightScopeSlot) — Δ‑move, requires LeftScopeSlot ⊂ RightScopeSlot.
• narrow(LeftScopeSlot, RightScopeSlot) — Δ‑move, requires RightScopeSlot ⊂ LeftScopeSlot.
• refit(LeftScopeSlot, RightScopeSlot) — normalization, requires LeftScopeSlot = RightScopeSlot.

Derived guard predicates (USM).

• coversSlice(ScopeSlot, SliceSlot) := (SliceSlot ∈ ScopeSlot).
• coversSet(ScopeSlot, SliceSetSlot) := (SliceSetSlot ⊆ ScopeSlot).

LawSet (USM). Serial composition uses intersection; parallel publication uses SpanUnion only with an explicit independence justification (§7.3).

AdmissibilityConditions (USM). Scope coverage predicates MUST be tri‑state under unknowns: unknown inputs yield unknown, and guards MUST either (a) abstain (fail closed) or (b) degrade trust in the admitting decision via R; unknown MUST NOT be implicitly coerced to false/0. (See also §7.1 and §10.1.)

Applicability (USM). USM governs Claim/Work/Publication scope objects inside a U.BoundedContext; coverage judgments are evaluated on explicit U.ContextSlice tuples (§6.1) and are not comparable/scorable as CHR values.

Audit (USM). Record scope‑aware decisions with the TargetSlice tuple, guard outcomes, and any Bridge+CL used (see §14.1).

Transport (USM). Cross‑context usage is Bridge‑only with explicit CL; CL penalties apply to R_eff = R · Φ(CL) and MUST NOT rewrite F or G (§7.4/§7.5).

Γ_timePolicy (USM). Γ_time is mandatory in slices and guards (§8.2); implicit “latest” is forbidden.

PlaneRegime (USM). Not applicable to set‑valued scope objects (no CL^plane effect on scopes).

Mechanism specialisation (USM; A.6.1:4.2.1). A bounded context MAY publish a specialisation of USM as either a refinement USM′ ⊑ USM (tighten LawSet/AdmissibilityConditions) or an extension USM ⊑⁺ USM′ (add new operators/slots). Any such specialisation SHALL (i) name its parent (USM), (ii) declare the morphism kind (⊑ vs ⊑⁺), (iii) preserve the same BaseType and SlotKinds for inherited operators (no renaming), (iv) avoid adding new mandatory inputs to inherited signatures. It MAY narrow ValueKinds/refModes monotonically and add admissibility constraints, but MUST remain substitutable for the inherited USM operators.

#U.ContextSlice — where scope is evaluated

Definition. U.ContextSlice is an addressable, context‑local selection of a bounded context comprising:

• Vocabulary & roles. The active terminology, role bindings, and local dictionaries.
• Standards & versions. Concrete versioned interfaces, schemas, notations, or service Standards in force.
• Environment selectors. Named parameters/ranges (e.g., temp, humidity, platform, jurisdiction, dataset cohort).
• Time selector Γ_time. A mandatory selector for the temporal frame of reference (point, window, or policy), disallowing implicit “latest”.

Semantics. All scope checks, guards, and compositions are evaluated inside an explicitly named U.ContextSlice. Cross‑context or cross‑slice usage MUST be mediated by a Bridge (Part B) with an explicit CL rating; see §7.4.

Addressability. A slice MUST be identifiable via a canonical tuple (Context, vocab‑id, Standard/version ids, env selector(s), Γ_time). A slice MAY be a singleton or a finite set if a guard tests multiple coherent sub‑conditions.

Slice key (minimal). A U.ContextSlice SHALL be addressable by a tuple containing at least: (Context, Standard/version ids (if any), environment selectors, Γ_time). Contexts MAY extend this tuple (e.g., vocab/roleset ids).

#U.Scope — the abstract set‑valued scope property (USM kind; not a CSLC measurement)

Definition. U.Scope ⊆ ContextSliceSet is a set‑valued USM property whose values are sets of U.ContextSlice where a given statement, behavior, or capability is fit‑for‑use. It is not numeric; its internal order is the subset relation ⊆. There is no “unit”. The primitive judgement is membership: slice ∈ Scope.

Guard (normative). U.Scope, U.ClaimScope (G), U.WorkScope, and U.PublicationScope are not U.Characteristics in the A.17/CSLC sense; do not include them as slots in any U.CharacteristicSpace, and do not attach normalizations/scores to them. They are USM scope objects.

Operations. USM admits:

• Intersection ∩ (serial composition).
• SpanUnion (parallel, independently supported coverage) only when an explicit named independence assumption is declared (features or characteristics named, validity window stated, evidence class cited). See A.6.1/USM LawSet for the normative template.
• Translate (Cross‑context mapping via Bridge).
• Widen / Narrow (monotone changes to the set).
• Refit (content‑preserving re‑expression; set equality).

Locality. U.Scope values are defined and reasoned about context‑locally. Translation between Contexts never occurs implicitly; see §7.4.

#U.ClaimScope (nick G) — scope of a claim (episteme)

Carrier. U.Episteme (claims, specifications, theories, policies).

Meaning. The set of U.ContextSlice where the claim holds as stated. This is G in the F–G–R triple. G is not “abstraction level”; it is the applicability area of the claim.

Expression. Authors SHALL declare Claim scope as explicit predicates or condition blocks (assumptions, parameter ranges, cohorts, platform/Standard versions, Γ_time windows).

Path composition (serial). Along any essential dependency path supporting the claim, the effective scope is the intersection of contributors’ Claim scopes (see §7.2). Empty intersection makes the path inapplicable.

Parallel support. Where independent lines of support justify disjoint areas, the episteme MAY publish a SpanUnion (see §7.3) limited strictly to the covered slices.

Δ‑moves.

• ΔG+ (widen). Replace scope S with S′ such that S ⊂ S′.
• ΔG− (narrow). Replace scope S with S′ such that S′ ⊂ S.
• Refit. Replace S with S′ where S′ = S (normalization, re‑parametrization).
• Translate. Map S across Contexts via a declared Bridge; CL penalties apply to R, not to F/G.

Orthogonality. Changes in F (form of expression) or D/AT (detail/abstraction tiers) do not change G unless the declared area of validity changes.

#U.WorkScope — scope of doing Work (capability)

Carrier. U.Capability (a system’s ability to deliver specified U.Work).

Meaning. The set of U.ContextSlice (conditions, Standards, platforms, operating parameters, Γ_time) under which the capability can deliver the intended Work at the declared measures, within declared qualification windows.

Expression. Capability owners SHALL declare U.WorkScope as explicit conditions/constraints over U.ContextSlice only (environment, platforms, Standards by version, resource regimes, Γ_time). Quantitative deliverables and operation windows are not part of the scope value:

• Declare targets as U.WorkMeasures (e.g., latency ≤ L, throughput ≥ T, tolerance ≤ ε) bound in guards (WG‑2).
• Declare inspection/recertification policies as U.QualificationWindow bound in guards (WG‑3). The use‑time admission requires all of: WorkScope covers JobSlice AND WorkMeasures satisfied AND QualificationWindow holds.

Method–Work gating. A Work step’s guard MUST check that the target slice is covered by the capability’s Work scope and that required measures and qualification windows are satisfied.

Composition and Δ‑moves. Work scope uses the same algebra as Claim scope (∩ / SpanUnion / translate / widen / narrow / refit). Translation across Contexts follows §7.4.

Separation from knowledge. Work scope does not assert a proposition about the world; it asserts deliverability of Work under conditions. Evidence for deliverability feeds R (Reliability) via measurements and monitoring.

Required guard facets (capabilities).

• U.WorkMeasures (mandatory). A set of measurable targets with units and tolerated ranges, evaluated on the JobSlice.
• U.QualificationWindow (mandatory for operational use). A time policy (point/window/rolling) stating when the capability is considered qualified; evaluated at Γ_time. These facets are separate from U.WorkScope and live in the R‑lane (assurance). They MUST be referenced in Method–Work guards (see §10.3 WG‑2/WG‑3).

#U.PublicationScope — scope of a publication view or publication form

Carrier. Publication faces, publication forms, interop publication forms, cards, lanes, and MVPK faces are publication-lane objects whose renderings live on carriers; the carrier remains separate from the publication view or form. Meaning. The set of U.ContextSlice where a publication (a view, card, or lane about some object or morphism) is admissible for use without introducing claims beyond its underlying carrier.

Relation to other scopes (normative).

• If the publication is about an episteme E: PublicationScope(view_E) ⊆ ClaimScope(E).
• If the publication is about a capability C: PublicationScope(view_C) ⊆ WorkScope(C).
• If the publication is about a composition and/or crosses Contexts: PublicationScope(view) ⊆ translate(Bridge, ⋂ scopes of contributors); CL penalties apply to R only (scope set membership is unaffected).

Expression. Authors SHALL declare U.PublicationScope as explicit predicates over U.ContextSlice (Context, Standard/version ids, environment selectors, Γ_time). It MAY be narrower than the underlying scope (e.g., due to pin availability, labeling, or audience constraints) but MUST NOT be wider.

Algebra & Δ‑moves. Inherits the USM algebra (∩ / SpanUnion / translate / widen / narrow / refit). Widen is permitted only when the underlying U.ClaimScope/U.WorkScope widens accordingly; otherwise the publication MAY refit or narrow.

Orthogonality to measurement. U.PublicationScope is a USM scope object (set‑valued), not a CHR Characteristic and MUST NOT appear as a slot in a U.CharacteristicSpace.

View refinement (profiles). When a stricter publication profile/view refines another (e.g., a typed card that requires additional pins), its U.PublicationScope MUST NOT be wider than that of the less formal view.

#Scope Algebra

#Membership & Coverage

• Membership judgement. slice ∈ Scope is the primitive check.

• Coverage guard. A guard “Scope covers TargetSlice” means either:

  • singleton: TargetSlice ∈ Scope, or
  • set: TargetSet ⊆ Scope.

• No implicit expansion. Absent an explicit declaration, guards MUST NOT treat “close” slices as covered; widening requires a ΔG+ change.

Tri‑state admissibility under unknowns (normative; aligns A.6.1).

• If any required input to a membership/coverage check is unknown (missing slice selector, unknown Standard version, unmappable Bridge leg, unspecified Γ_time, etc.), the check result is unknown, not false.
• Guards MUST either abstain (fail closed) or explicitly route the outcome through an R‑lane degradation policy; unknown MUST NOT be coerced to false/0.

#Serial Composition (Intersection)

Rule S‑INT (serial). For an essential dependency chain C1 → C2 → … → Ck that supports a claim/capability, the effective scope along that chain is:

Scope_serial = ⋂_{i=1..k} Scope(Ci)

If Scope_serial = ∅, the chain is inapplicable and MUST NOT contribute to published scope.

Monotonicity. Adding a new essential dependency can only narrow (or leave unchanged) the serial scope.

#Parallel Support (SpanUnion)

Rule P‑UNION (parallel). If there exist independent support lines L₁,…,Lₙ for the same claim/capability, each with serial scope S_i, the publisher MAY declare:

Scope_published = SpanUnion({S_i})  =  ⋃_{i=1..n} S_i

Constraints.

• Independence MUST be justified (different support lines must not rely on the same weakest link).
• The union MUST NOT exceed the union of supported slices; “hopeful” areas are disallowed.
• Publishers SHOULD annotate coverage density/heterogeneity (informative) to aid R assessment, but numeric “coverage” is not part of G.
• Independence criterion. Support lines in a SpanUnion MUST be partitioned so that each line has a set of essential components disjoint from the others’ essential components (no shared weakest link). The partition (or a certificate thereof) SHALL be referenced in the publication.

#Why a G-ladder/levels/scales is not needed (and must not be introduced)

1) G is not an ordinal scale; it is set-valued. Under USM, U.ClaimScope is a set‑valued USM scope object over U.ContextSlice. The only well‑typed primitives are membership and set operations (⊆, ∩, ⋃). Imposing ordinal “levels” such as G0…Gk violates the type discipline and produces non‑invariant behavior (the same set could be “rated” with different numbers under different heuristics). (See also LEX‑CHR‑STRICT.)

2) G composes via ∩ / SpanUnion, not via min / avg. USM already fixes composition: along a dependent path use intersection; across independent support lines publish SpanUnion. None of these operations relies on (or preserves) any linear order. An ordinal “G ladder” invites people to take minimums/averages, which is incorrect for sets and breaks the established algebra.

3) A G ladder drags in “abstraction level,” which is orthogonal. Early “G ladders” effectively encoded abstraction/typing (instances → patterns → formal classes/types → up‑to‑iso). That is valuable didactics, but not applicability. We have already separated these concerns: abstraction is captured, if needed, by U.AbstractionTier (AT) as an optional facet; applicability is U.ClaimScope (G).

4) A G ladder breaks locality and Bridge semantics. Cross‑context transfer maps a set Scope via a Bridge and penalizes R by CL. There is no canonical way to “translate” an ordinal G level between Contexts: the mapped area may be strictly narrower or differently factored. Level numbers would become non‑portable, causing hidden loss or inflation of trust. With USM, we translate sets and keep the CL penalty where it belongs—in R, not in G.

5) A G ladder duplicates ESG guards without adding decision power. What teams often want to “compress into a G number” is actually (a) the quality of expression and (b) the completeness of the declared scope. The first is an F threshold (e.g., require U.Formality ≥ F4 so the scope is predicate‑like and addressable); the second is handled by explicit ESG guards: “Scope covers TargetSlice,” “Γ_time is specified,” and “freshness window holds” (R‑lane). A ladder for G adds confusion but no additional control.

Normative directive. U.ClaimScope (G) SHALL remain a set‑valued USM scope object; no ordinal or numeric ladder SHALL be defined for G. If a profile needs scalar reporting, it MAY publish an explicit report‑only proxy CoverageMetric(G), but CoverageMetric(G) MUST NOT substitute for G in norms, gates, bridge semantics, or CL routing. Authoring and gating SHOULD use F thresholds (C.2.3) and explicit guard predicates (A.2.6) rather than pseudo‑levels of G.

#Translation across Contexts (Bridge & CL)

Rule T‑BRIDGE. To use a scope in a different bounded context (room), an explicit Bridge MUST be declared with:

• Mapping. A documented mapping from source to target U.ContextSlice vocabulary/characteristics.
• Congruence Level (CL). A rating of mapping congruence.
• Loss notes. Any known losses, assumptions, or non‑isomorphisms.

Effect. The mapped scope is T(Scope) in the target Context. CL penalties apply to R (the trust in support and evidence), not to F or G. If mapping is coarse, the publisher SHOULD also narrow the mapped scope to the area where losses are negligible (best practice, not a requirement).

#Δ‑Operations (Widen, Narrow, Refit)

• ΔG+ (widen). Monotone expansion: S ⊂ S′. Requires new support or Bridges with sufficient declared CL.
• ΔG− (narrow). Monotone restriction: S′ ⊂ S. Often used to remove areas invalidated by new findings.
• Refit. S′ = S after normalization (e.g., re‑parameterization, changing units, factoring common predicates). Refit MUST NOT alter membership.

Refit (normalization). A refit MUST preserve membership exactly (S′ = S). Any change that alters boundary inclusion (due to rounding, unit conversion, discretization) is a ΔG± change, not a refit.

Edition triggers. Any change that alters the published set (ΔG±) is a content change and MAY trigger a new edition per Context policy (see A.2.x on editions). Refit is not a content change.

#Invariants

• I‑LOCAL. All scope evaluation is context‑local. Cross‑context usage MUST follow §7.4.
• I‑SERIAL. Serial scope is an intersection; it cannot grow by adding dependencies.
• I‑PARALLEL. Parallel scope MAY grow by union, but only where independently supported.
• I‑WLNK. Weakest‑link applies to F and R on dependency paths; G follows set rules (∩ / ⋃).
• I‑IDS. Idempotence: Intersecting or unioning a set with itself does not change it.
• I‑EMPTY. Empty scope is a first‑class value; guards MUST treat it as “not applicable”.

#Empty & Partial Scopes

• Empty scope (∅). The claim/capability is currently not usable anywhere in the Context; guards MUST fail.
• Partial scope. Publishers SHOULD avoid “global” language when actual scope is thin; instead, publish explicit slices and (informatively) coverage hints to guide R assessment.

#Locality, Time & Version Semantics

#context‑locality

Scopes are owned and evaluated within a U.BoundedContext. State assertions (ESG/RSG) and Method–Work gates MUST NOT assume that a scope declared in another Context applies verbatim; see §7.4.

#Time selector Γ_time

Every scope declaration and every guard MUST specify a Γ_time selector (point, window, or policy such as “rolling 180 days”) whenever time‑dependent assumptions exist. Implicit “latest” is forbidden. When Γ_time differs between contributors, serial intersection resolves the overlap.

#Standards, versions & notations

Scope predicates SHALL name Standards/interfaces/schemas by version. Changing symbols/notations with a faithful mapping does not change G (it may change CL for the mapping and thus affect R).

#Determinism of evaluation

Given fixed inputs (slice tuple, declared scope), the membership judgement MUST be deterministic. Guards SHALL fail closed (no membership ⇒ no use).

#Interaction with R (freshness & decay)

For empirical claims and operational capabilities, R typically binds evidence freshness windows. Scope does not decay with time; trust in the support does. Guards MAY combine “Scope covers” with “Evidence freshness holds” as separate predicates.

#Lexical Discipline (Part E compliance)

L‑USM‑1 (names). Use Claim scope (G) for epistemes, Work scope for capabilities, and Publication scope for publication carriers. Use Scope only when discussing the abstract mechanism. Avoid naming any characteristic as “applicability,” “envelope,” “generality,” “capability envelope,” or “validity”.

L‑USM‑2 (Work/Run). Prefer Work/Run vocabulary from A.15 for system execution contexts. Do not introduce “operation/operating” as characteristic names; use Work scope.

L‑USM‑3 (Validation). “Validation/Validate” remain reserved for LA in assurance lanes (Part B). Do not name a scope object “validity”.

L‑USM‑4 (Domain). “Domain” is a descriptive convenience. Scopes are evaluated on Context slices; guards SHALL reference slices, not generic “domains”.

L‑USM‑5 (First mention). On first use in a Context, include the parenthetical nick: “Claim scope (G)” to preserve the F–G–R mapping.

#Guard Patterns (ESG & Method–Work)

#Common guard shape

A scope‑aware guard has the form:

Guard := ScopeCoverage AND TimePolicy AND (EvidenceFreshness?) AND (BridgePolicy?)

Admissibility note (normative; A.6.1 alignment). If ScopeCoverage is unknown (due to unknown slice keys, unmappable translation, missing Γ_time, etc.), the guard MUST NOT silently treat this as false. It MUST either abstain (fail closed) or apply an explicit R‑lane degradation policy.

Where:

• ScopeCoverage: Scope covers TargetSlice (singleton or finite set), see §7.1.
• TimePolicy: explicit Γ_time selector(s); implicit “latest” is forbidden (§8.2).
• EvidenceFreshness: optional R‑lane freshness/decay predicates; separate from ScopeCoverage (§8.5).
• BridgePolicy: required if the Scope and TargetSlice are in different Contexts; declares Bridge, CL, loss notes (§7.4).

The guard fails closed (no membership ⇒ denial), and evaluation is deterministic given the slice tuple (§8.4).

#ESG guard families (epistemes)

EG‑1 - ClaimScopeCoverage (mandatory). The state transition MUST include a predicate:

U.ClaimScope(episteme) covers TargetSlice

• Singleton: TargetSlice ∈ ClaimScope.
• Finite set: TargetSet ⊆ ClaimScope.

EG‑2 - Formality threshold (if required by ESG). When rigor is gated, the guard MUST reference C.2.3:

U.Formality(episteme) ≥ F_k

EG‑3 - Evidence freshness (R‑lane). If the state implies trust, a separate predicate MUST assert freshness windows for bound evidence:

Fresh(evidence, window)  AND  (NoExpiredBindings)

EG‑4 - Cross‑context usage. If TargetSlice.Context ≠ episteme.Context, the guard MUST require a declared Bridge and CL:

Bridge(source=episteme.Context, target=TargetSlice.Context)  AND  CL ≥ c

Effect: CL penalties apply to R, not to F/G (§7.4). The ESG guard MAY also narrow the mapped Claim scope when mapping losses are known.

EG‑5 - ΔG triggers. If the transition publishes a wider Claim scope (ΔG+), the guard MUST capture the new support or the new Bridge and, if Context policy so dictates, mint a new edition (PhaseOf).

EG‑6 - Independence for SpanUnion (when claiming parallel scope). When the episteme declares a SpanUnion across independent lines, the guard MUST include an independence justification (pointer to the support partition). No independence ⇒ no union.

(Informative note.) Managers often combine EG‑1 (coverage) + EG‑2 (F threshold) + EG‑3 (freshness) for “Effective” or “Approved” states, and EG‑4 when adopting claims across Contexts.

#Method–Work guard families (capabilities)

WG‑1 - WorkScopeCoverage (mandatory). A capability can be used to deliver a Work step only if:

U.WorkScope(capability) covers JobSlice

WG‑2 - U.WorkMeasures satisfied (mandatory for deliverables). Guards MUST bind quantitative measures that the capability promises in the JobSlice:

SLO/target measures satisfied (latency ≤ L, throughput ≥ T, tolerance ≤ ε, … )

WG‑3 - U.QualificationWindow holds (mandatory for operational use). Operational guards MUST assert that qualification windows (qualification/inspection/recert intervals) hold at Γ_time:

ValidityWindow(capability) holds at Γ_time

WG‑4 - Cross‑context use of capability. If the JobSlice is in another Context:

Bridge(source=capability.Context, target=JobSlice.Context)  AND  CL ≥ c

CL penalties affect R (confidence in deliverability), not Work scope; however, the guard SHOULD narrow the mapped Work scope to account for known mapping losses.

WG‑5 - Δ(WorkScope). When widening Work scope (new operating ranges/platforms), the guard MUST require evidence at the new slices (measures + qualification windows). Refit (e.g., new units/parametrization) requires no new evidence.

#Bridge‑aware guard macro (reusable)

A reusable macro for Cross‑context guards:

Guard_XContext(Scope, TargetSlice) :=
    exists Bridge b: (b.source = owner(Scope).Context AND b.target = TargetSlice.Context)
AND CL(b) ≥ c
AND Scope’ = translate(b, Scope)
AND Scope’ covers TargetSlice
AND (Apply CL penalty to R)

• Owner(Scope). The carrier that declares the scope: an Episteme (for U.ClaimScope), a Capability (for U.WorkScope), or a Publication carrier (for U.PublicationScope).
• Translate(b, Scope). The partial mapping of a set of source slices to target slices induced by Bridge b. If a source slice is unmappable, it is dropped. The result is a set of target slices; CL penalties apply to R only.
• Penalty to R: applied per trust calculus; F and G remain as declared.

#Selector policy (Γ_time)

All ESG and Method–Work guards MUST spell out Γ_time:

• Point (“as of 2026‑03‑31T00:00Z”).
• Window (“rolling 180 days”).
• Policy (“last lab calibration within 90 days”).

Implicit “latest” is not allowed. If multiple contributors declare different policies, serial intersection computes the overlap (§8.2).

#Conformance Checklist (USM)