#Part A - Kernel Architecture Cluster

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

#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

#Holon Ontic Foundation (U.Holon and Admitted Holon Kinds)

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 rely on parts, wholes, boundaries, acting systems, roles, methods, work, architecture, or descriptions.

Typical moments:

• a team calls everything a "system" and then asks physical or operational questions about theories, documents, models, dashboards, or descriptions;
• an episteme is treated as an acting agent that decides, performs work, authorizes, promises, or revises itself;
• a product, organization, machine, document family, research program, bounded context, discipline, work occurrence, or model family must be treated as a whole with parts;
• a list, batch, fleet, pool, clientele, community, or supplier base is expected to act, but no acting system has been admitted;
• architecture or selected-structure claims need the holon whose structure is being selected.

First useful move. Name the U.Entity under concern. Then decide whether the current claim also admits it as U.Holon, and whether a direct governing pattern admits a more specific holon kind such as U.System, U.Episteme, U.Method, U.Work, U.BoundedContext, or U.Discipline.

What goes wrong if missed. A document edits itself, a theory gets ports, a list becomes an organization, a lathe becomes the super-holon of the workpiece it changes, and architecture is discussed without naming the holon whose structure is selected.

What this buys. FPF gets one compact part-whole foundation without turning every whole into a physical system: identity starts at U.Entity; part-whole treatment starts at U.Holon; acting work attaches to U.System; claim-bearing knowledge is carried by U.Episteme; method holonhood is governed by U.Method; other admitted holon kinds keep their own governing patterns.

Not this pattern when.

• If the current question is local vocabulary, local invariant, role taxonomy, or meaning inside one semantic frame, use A.1.1.
• If the current question is episteme slot discipline, use C.2.1.
• If the current question is relation vocabulary or component, portion, aspect, and phase discipline, use A.14.
• If the current question is constructive part-whole grounding, use C.13; use B.3.5 for Working-Model assurance grounding.
• 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 transformation, method, role, work, capability, or functioning, use the direct governing pattern before relying on A.1.

#Problem Frame

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

A.1 separates four questions that are often collapsed:

• reference: what can be individuated as U.Entity;
• part-whole treatment: what can be considered as U.Holon in a bounded context;
• acting eligibility: what can be admitted as U.System;
• claim-bearing knowledge: what can be admitted as U.Episteme.

Other admitted holon kinds are not created by title, slot position, or ordinary-language label. They remain governed by their direct patterns. Current accepted examples include U.Method under A.3.1, U.Work under A.15.1, U.BoundedContext under A.1.1, and U.Discipline under C.20.

#Problem

Without A.1:

1. System-bias spreads. Physical and operational assumptions are projected onto epistemes, descriptions, theories, documents, dashboards, and source records.
2. Epistemes become agents. A document, model, theory, pattern, or report is said to decide, promise, authorize, perform work, or revise itself.
3. Collections become collectives by wording. A set of people, services, files, claims, assets, or suppliers is treated as an acting whole without boundary, coordination, role assignment, capability, method, or work evidence.
4. Transformation becomes containment. A system that changes another holon is treated as that holon's super-holon or as a part-whole relation by the fact of interaction.
5. Architecture loses its grounding holon. A structure, view, graph, diagram, or architecture claim floats free of the holon whose selected structure is under concern.
6. Slot position creates false kinds. A value in a role, source, transformed-object, evidence, publication, or described-holon slot is treated as a new ontology by local name.

#Forces

#Solution

Use A.1 to decide whether the current object is only a referenceable entity, a holon, or a directly admitted holon kind.

U.Entity
  U.Holon
    U.System
    U.Episteme
    U.Method           only under A.3.1 and direct method-composition patterns
    U.Work             only under A.15.1
    U.BoundedContext   only under A.1.1
    U.Discipline       only under C.20
    named C.3 U.Kind   only when a direct governing pattern admits holon treatment

This is not a classical taxonomic ladder and not a publication hierarchy. It is a governed admission discipline for part-whole treatment in FPF.

#U.Entity

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

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

Do not apply holon aggregation, part-whole grounding, acting-system roles, or architecture claims to a bare U.Entity unless a current pattern also admits the entity as U.Holon or as a directly governed holon kind.

#U.Holon

U.Holon is the broad part-whole EntityOfConcern: a U.Entity considered as a whole with parts and as a possible part of larger wholes in a bounded context.

A holon claim is admissible only when the current text names the bounded context, the identity or recognition rule, the current part relation, and the governing pattern that admits the object under that part-whole treatment.

The A.1 holon slot relation is:

HolonSlotRelation@Context:
  holonRef: U.Holon
  boundedContextRef: U.BoundedContext
  identityOrRecognitionRule:
  partRelationRefs:
  selectedStructureRefs?
  holonDelimitationRelationRefs?
  holonBoundaryCrossingRelationRefs?
  containingWholeRefs?
  admittedHolonKindRef?: U.System | U.Episteme | U.Method | U.Work | U.BoundedContext | U.Discipline | named C.3 U.Kind admitted by a direct governing pattern

This relation is a selected SlotRelation expression, not a new U-kind and not a record that acts. Under open-world discipline, an omitted slot means "not current or not recovered for this claim", not "absent in the world".

#Admitted Holon Kinds

Current accepted holon-kind examples are:

• U.System, governed here as the acting physical or operational holon kind;
• U.Episteme, governed here only as a non-agentive claim-bearing holon, with full slot discipline in C.2.1;
• U.Work, governed by A.15.1 as a dated 4D occurrence holon;
• U.BoundedContext, governed by A.1.1 as a semantic-frame holon;
• U.Discipline, governed by C.20 as a field-level practice-and-knowledge holon;
• U.Method, governed by A.3.1 and method-composition patterns such as B.1.5 as a non-agentive method holon whose submethods compose into a whole method across levels.

No blank "other kind" escape hatch is selected. If a source claims another holon kind, the current FPF use must name the concrete C.3 U.Kind, the part-whole relation, the direct governing pattern, and the slot discipline that makes holon treatment admissible before any part-whole, architecture, role, work, evidence, or source-use claim relies on it.

Holon admission is decided by own constructive assembly with meta-holon transition, not by agentivity or wording. A candidate kind can be treated holonically when a bounded context can select the participating objects from the surrounding practice or world, fix their boundaries, assemble them through a current part-whole relation into a whole, and recover a whole-level property, capability, constraint, function, claim-bearing structure, or other characteristic that belongs to the assembled whole rather than to any single part or to a label. The resulting whole must also be eligible to become a part in a larger assembly. Grounding is the agreement discipline for that construction: it fixes the selected objects, boundaries, part relation, assembly operation, MHT evidence, and governing patterns. Relations may arrange, constrain, assign, qualify, or describe parts; those relations do not become parts by that fact.

U.Role and U.Method are therefore not decided by whether they act. U.Episteme already shows that a non-agentive object can be a holon. The ontology decision is: U.Method is a non-agentive holon kind, and U.Role is not a holon kind. A method can have submethods composing into whole methods with whole-level preconditions, effects, invariants, interfaces, constraints, and assurance hooks; the resulting method can participate in a larger method. A step label or step description is not a method part by label: it must first be recovered as a U.Method submethod rather than as a method-description node, order relation, work-plan item, or work occurrence. A role value names what a holder is being in a context; its assignment, state, capability, responsibility, permission, commitment, obligation, method participation, and role relation structure are neighboring objects, relation positions, or descriptions, not role parts.

#U.System

U.System is an acting physical or operational holon kind. It can bear work-facing role assignments, capabilities, methods, mechanisms, work occurrences, transformation participation, and responsibility-bearing claims when the direct neighboring patterns make those claims current.

The A.1 system participation relation is:

SystemParticipationRelation@Context:
  systemRef: U.System
  boundedContextRef: U.BoundedContext
  holonDelimitationRelationRef?
  roleAssignmentRefs?
  capabilityRefs?
  methodRefs?
  methodDescriptionRefs?
  mechanismRefs?
  workPlanRefs?
  workOccurrenceRefs?
  transformationParticipationRefs?
  functioningOrFunctionalElementRefs?
  evidenceRelationRefs?
  assuranceRelationRefs?
  temporalAspectRefs?
  dynamicsAspectRefs?

This relation links acting-system participation across role, capability, method, mechanism, work, transformation, functioning, evidence, assurance, temporal, and dynamics concerns. It does not collapse those concerns into one kind. Role assignment remains role discipline; method remains method discipline; performed work remains work discipline; transformation remains U.Transformation; functioning and functional element remain with their direct governing patterns.

#U.Episteme

U.Episteme is a claim-bearing, non-agentive holon kind. It can be changed, used, cited, published, represented, versioned, structured, compared, interpreted, or relied on by acting systems, but it does not act by itself.

Use C.2.1 and the episteme family for episteme slot relation, claim graph, viewpoint, reference scheme, evidence relation, publication relation, source-use relation, and claim-bearing structure. A.1 only says that an episteme can be treated as a holon when part-whole treatment of the claim-bearing object is current.

Do not say that an episteme decides, approves, performs work, promises, revises itself, authorizes action, or bears responsibility. A system in role may do those things with or about an episteme.

#Holon Delimitation And Boundary Crossing

Do not create U.Boundary or U.Interaction from boundary or interaction wording.

Use HolonDelimitationRelation@Context when the current claim is about where the holon is delimited in a bounded context: identity rule, membership or part relation, environment relation, selected structure, or current boundary condition.

Use HolonBoundaryCrossingRelation@Context when the current claim is about a relation crossing that delimitation: transformation, signal, control, measurement, source use, publication use, evidence relation, probe relation, coupling, or another direct relation. If bounded change under conditions is current, use A.3.4 for U.Transformation; the boundary-crossing relation may point to it but is not the transformation itself.

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

External holon vocabularies do not admit FPF kinds by label. If a source says AgentHolon, OrganisationHolon, DataHolon, ProcessHolon, Portal, Projection, or a similar semantic-web holon class, recover the FPF claim before using it. Acting-agent and organization claims require U.System admission; data, document, and projected-content claims usually require U.Episteme, publication, source, evidence, or description patterns; process-holon wording requires work, method, work-plan, or transformation patterns; portal or traversal wording requires an access, boundary-crossing, policy, or evidence relation. A.1 admits only the holon or system claim when that claim is current.

Do not call a Markov blanket a holon boundary, interface, interface module, physical component, statistical separator, or agency proof until the current claim is recovered. If source wording says Markov blanket, first decide whether it names accepted local Markov dynamics, a mathematical or probabilistic lens, a holon delimitation or boundary-crossing relation, a physical interface module or component, a functional element, a boundary description or publication, or an agency-threshold claim. Apply the direct governing pattern. A.1 admits only the holon and delimitation claim when those are current.

#Collections, Collection-As-Whole, And Acting Collectives

A list, set, batch, fleet, pool, clientele, community, supplier base, or coverage zone does not become a U.System by wording.

First recover whether the source claims:

• membership only, governed by A.14 relation vocabulary;
• collection-as-whole constructive grounding, governed by C.13 and B.3.5 where assurance grounding is current;
• whole-level characteristic, governed by C.16;
• acting collective system, governed by U.System admission plus A.15 and role, method, and work patterns;
• whole reidentification, governed by B.2.

An acting collective U.System needs boundary, coordination, role assignments, capability or method evidence, and work-facing participation. If those are not current, keep the object as a collection or collection-as-whole claim under direct governing patterns.

#Constructional Grounding

A.1 names holon admission. It does not replace part-whole grounding.

Use:

• A.14 for relation vocabulary such as component, portion, aspect, phase, member, and part-whole relation;
• C.13 for constructive grounding such as Gamma_m.sum, Gamma_m.set, or slice treatment when the constructional grounding question is current;
• B.3.5 for Working-Model assurance grounding when the part-whole claim is used for assurance or evidence.

FPF avoids unrestricted composition. A set of nearby objects, a graph, a diagram, a role bundle, a method algebra, or a source table does not become a holon merely because it can be described as a whole.

#Slot Position Does Not Create A Kind

A system in a role-assignment holder slot remains a system. An episteme in an EntityOfConcern slot remains an episteme. A holon whose structure is described does not become the description of that structure. A system changing another holon may fill transformation participation slots without becoming that holon's super-holon. A publication, dashboard, model, or digital twin may describe a holon without becoming that holon.

Use the direct governing pattern for the current slot relation before creating a durable name.

#Archetypal Grounding (Worked Cases)

#Pump As Acting System

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

HolonSlotRelation@Context:
  holonRef: Pump #37
  boundedContextRef: PlantLineB.Maintenance.2026
  identityOrRecognitionRule: asset tag plus installed pump boundary
  partRelationRefs: casing, impeller, seals, motor, inlet flange, outlet flange
  holonDelimitationRelationRefs: casing plus inlet and outlet flange delimitation
  holonBoundaryCrossingRelationRefs: water flow, electrical supply, control signal
  admittedHolonKindRef: U.System

SystemParticipationRelation@Context:
  systemRef: Pump #37
  roleAssignmentRefs: cooling-water circulation role
  capabilityRefs: flow-rate envelope
  methodRefs: maintenance method selected by plant rules
  workOccurrenceRefs: performed inspection WO-1842
  transformationParticipationRefs: moving water under operating conditions

The pump can bear a role, participate in transformations, and have selected structures. The work order, dashboard, and maintenance procedure are epistemes or publications unless a direct pattern says otherwise.

#Scientific Theory As Episteme Holon

Newtonian gravitation in a selected edition is a U.Episteme holon in a physics-education bounded context.

HolonSlotRelation@Context:
  holonRef: Newtonian gravitation, selected textbook edition
  boundedContextRef: PhysicsEducation.SelectedEdition
  identityOrRecognitionRule: selected claims, definitions, reference scheme, and examples
  partRelationRefs: laws, definitions, derivations, diagrams, exercises, evidence relations
  admittedHolonKindRef: U.Episteme

The theory does not teach itself, revise itself, or authorize lab work. A teacher, student, author, reviewer, or software system in role may explain, revise, publish, compare, or use the episteme.

#Fleet As Collection Or Acting Collective

A fleet list is a membership claim. Fleet availability is a whole-level characteristic. A fleet-coordination organization that coordinates vehicles, drivers, rules, and work can be an acting collective U.System only after boundary, coordination, role assignments, capability or method evidence, and work-facing participation are recovered.

If a source says "the fleet responded", A.1 does not accept the sentence by wording. Recover the actual claim: individual vehicle work, fleet-coordination system work, collection-as-whole characteristic, or B.2 whole reidentification.

#Lathe Changing A Workpiece

A lathe can change a workpiece during manufacturing without becoming the workpiece's super-holon.

Use A.3.4 for the bounded transformation: transformed object, initial condition, post-state or delta, boundary conditions, acting system participation, method, work occurrence, and evidence. Use A.14 or C.13 for part-whole only when parthood is independently admitted.

#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 collection as an acting collective;
• boundary-bias: treating boundary words, diagrams, folders, or sections as holon delimitation by appearance;
• interaction-bias: using one word for transformation, signal, source use, publication use, evidence relation, probe relation, and control relation;
• math-lens drift: treating graph, algebra, matrix, tuple, or embedding expressions as the ontology-side structure by spelling;
• publication-form bias: treating a document, dashboard, model, register, or digital twin 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, work occurrences, bounded contexts, disciplines, and research programs without making them all systems.
• Acting work stays attached to systems in roles.
• Epistemes can be changed, described, compared, published, and relied on without becoming agents.
• Architecture and selected-structure claims gain a grounding holon.
• Collection-as-whole and acting collective claims become inspectable instead of lexical.

Costs:

• Authors must stop using "system", "boundary", "interaction", "level", "emergence", or "collection" as umbrella substitutes.
• A holon claim must say enough about context, identity, and part relation to be reviewable.
• 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

A.1 prevents category errors by separating individuation, part-whole treatment, acting eligibility, and claim-bearing. U.Entity gives the minimal referenceable object. U.Holon adds part-whole treatment in a bounded context. U.System adds acting eligibility. U.Episteme adds claim-bearing structure without agentivity. U.Work, U.BoundedContext, and U.Discipline are holon-kind examples only through their governing patterns.

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 constructional stance is conservative: FPF avoids unrestricted composition and uses A.14, C.13, and B.3.5 before a part-whole claim is relied on for another claim or work occurrence. This keeps holonic thinking useful without letting every collection, expression, graph, or source label become a holon.

#SoTA-Echoing

Treat a stronger source as current only when it changes the root split among U.Entity, U.Holon, U.System, admitted holon kinds, delimitation, boundary crossing, or publication-form separation. A new tool, notation, or diagram style is not enough unless it changes that ontology-side claim.

#Relations

• Builds on: E.24 for ontic introduction discipline, E.24.UK for U-kind admission discipline, and A.6.5 for slot relation discipline.
• Coordinates with: A.1.1 for bounded context, A.14 for relation vocabulary, C.13 for constructive grounding, B.3.5 for Working-Model assurance grounding, A.22 for selected structure, C.30 for architecture, C.2.1 for episteme slot relation, A.15 and A.15.1 for role-method-work and performed work, A.3.4 for transformation, C.20 for discipline, and E.10.ARCH for wording-use restoration.
• Used by: patterns that need a grounding holon, admitted holon kind, acting system, non-agentive episteme, part-whole relation, collection-versus-collective distinction, delimitation relation, or boundary-crossing relation.

#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 an admitted U.System holder, such as a system, organization-as-system, person, team, tool, agent, machine, motor, pump, or component, is being in a bounded context before method, plan, work, transformation, functioning, evidence, responsibility, or naming claims can be made safely.

Typical moments:

• a project sentence says "engineer", "reviewer", "operator", "supplier", "model verifier", "agent", "service provider", "drive motor", "cooling circulator", "load-bearing brace", or another role-like name, and it is unclear what holder, context, and work, transformation, or functioning 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;
• a role boundary is being decomposed into factors, states, responsibilities, or method participation, and the project must recover the current neighboring object instead of treating role as a holon.

Primary EntityOfConcern. The EntityOfConcern is U.Role: a context-bound enactment-facing role value in the role ontologicalNeighborhood. A role value names what an admitted U.System holder is being for a bounded context when method admission, role-state checking, transformation or functioning participation, or work attribution depends on that role. U.Role is a root U-kind, but it is not an admitted holon kind: role decompositions resolve to assignment, state, capability, responsibility, permission, commitment, obligation, method, work, or role-relation owners rather than to role parts.

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-fit condition, functional or transformation participation, method role-admission condition, 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-admission 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 context-bound enactment-facing role value. Enactment-facing does not mean "human job" or "social agent only": a motor can be assigned as a drive motor, a pump can be assigned as a cooling circulator, and a valve can be assigned as a regulator inside a functional or transformation context. A method or method description may name role-admission conditions; performed work cites a U.RoleAssignment; transformation and functioning claims may also need the same role value. A role becomes operational through neighboring relations, especially U.RoleAssignment in A.2.1, role-method-work alignment in A.15, transformation participation in A.3.4, and functional precision restoration in A.6.F when function wording is current. 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.
8. Role-whole overclaim. A role is decomposed into factors, responsibilities, states, permissions, obligations, or method participation and then treated as a holon, although U.Role is not admitted as a holon kind. The recoverable objects are neighboring relations or values, not role parts.

#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 admitted U.System holder being, in this bounded context, for the current method, transformation, functioning, or work 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 enactment-facing role value: a reusable value that names what an admitted U.System holder is being in a bounded context. It is enactment-facing because its primary practical use is to govern or explain role assignment, method role-admission conditions, transformation or functioning participation, 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, not a system part, not the function itself, 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 an admitted U.System selected by the governing work, transformation, functioning, or method pattern as the system-like performer for the bounded context. The word "performer" here includes physical and operational performance by motors, pumps, valves, organisms, teams, services, and devices; it does not imply consciousness, social agency, or responsibility unless a neighboring pattern makes that claim current. 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 boundary. A role boundary is grounded by a bounded context, the holder class or known holders, the assignment or admission use, the method, transformation, functioning, or work claim, and any current role description, role-state relation, role-relation structure, capability-fit condition, method role-admission condition, or evidence about performed work. A proposed decomposition of a role does not supply role holonhood. Recover whether the decomposed objects are role-admission fit relations, factors or qualifications, bundle expressions, separate role values, role-state refinements, capability-fit conditions, responsibility, permission, commitment, or obligation relations, or coupled method/work structures.

Do not infer role parts from slots or relation richness. Systems hold roles. Role assignments, role states, evidence uses, and other relation-bearing structures may have SlotSpecs. Epistemes such as role descriptions may have constituent parts. Those slots and description parts are not parts of the U.Role value.

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 an admitted U.System selected as system-like performer for the current work, transformation, functioning, 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-admission substitution;
• role incompatibility;
• role bundles;
• role-state predicates;
• holder eligibility constraints;
• capability-fit conditions;
• method role-admission conditions 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 DriveMotorRole, CoolingCirculatorRole, BridgeInspectorRole, ClinicalTrialCoordinatorRole, ModelCardReviewerRole, or ShipyardOperatorRole. Define them in their bounded context and connect them to role assignment, capability, method, transformation, 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-admission 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 admitted U.System 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 admitted U.System holder 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 claim decomposes a role, do not open role mereology. Use A.2.7 and neighboring owners to recover role-admission fit, factor or qualification, bundle expression, separate role value, role-state refinement, capability-fit condition, responsibility, permission, commitment, or obligation relation, or coupled method/work structure.
5. If the phrase names ability, recover capability under A.2.2.
6. If the phrase names performed work, intended work, or governing method, use A.15 and its neighboring method and work patterns.
7. 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.
8. 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 admitted U.System holder is being something in a bounded context for work, transformation, functioning, method, or attribution. 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 admitted U.System holder, such as a system, organization-as-system, person, team, service, agent, device, motor, pump, or component, holds which enactment-facing U.Role in which bounded context, and when that assignment is current enough to satisfy a method role-admission condition, check role state, plan or attribute work, transformation participation, or functioning.

Typical moments:

• a work record says that "Alice reviewed", "Robot-7 inspected", "CI bot deployed", "Motor-M1 drove Pump-A", or "the operations team approved" and the role, holder, bounded context, or assignment window is missing;
• a method or method description names role-admission conditions, but the project has not linked those roles to concrete performers;
• a role state, capability-fit condition, separation-of-duties rule, or work gate depends on who holds the role now;
• a source phrase gives an episteme an "evidence role", "standard role", "status role", or "requirement role" and the text must be normalized 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 assignment relation value for enactment-facing roles. It links an admitted system holder, a U.Role, a U.BoundedContext, and any assignment-currentness window or assignment source that is current for the claim. The holder may be a person, team, organization, service, device, motor, pump, component, organism, or other U.System; role holding does not imply human agency or responsibility unless a neighboring pattern makes that stronger claim current.

Primary working reader. The first reader is an engineer-manager, analyst, or FPF author who needs work attribution, role admission, role-state checks, method role-admission conditions, 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-fit condition, method role-admission condition, 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 holder-in-role admission. It keeps role values reusable, method role-admission conditions checkable, work attribution replayable, 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-admission 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", "coordinator", "drive motor", and "cooling circulator" 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, transformation, functioning, 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 an enactment-facing role. A report can be used as evidence, but it does not perform the review that produced it. A method description can state ReviewerRole as a role-admission condition, 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 enactment-facing: its holder is an admitted U.System selected as system-like performer by the governing method, work, transformation, or functioning pattern. "Performer" includes physical and operational performance by machines, components, organisms, services, teams, and people; it does not imply consciousness, intention, legal accountability, or ethical responsibility unless a neighboring pattern makes that stronger claim current. 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 an enactment-facing U.Role to an admitted system 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 an admitted U.System selected as system-like performer by the governing work, transformation, functioning, 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-admission conditions 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. For machines and components, this includes physical or operational work such as driving, pumping, regulating, heating, cooling, sensing, stabilizing, or transforming a state under the governing functional or transformation context.

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 bounded transformation is governed by [A.3.4](/generated/patterns/A.3.4) when the work is claimed as transformation participation;
• functional wording is restored through [A.6.F](/generated/patterns/A.6.F) when the role is named by what the holder does functionally;
• the selected method is governed by [A.3.1](/generated/patterns/A.3.1);
• the method description or role-admission 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

Source text may name U.RoleEnactment or RoleEnactment. In FPF, role enactment is a derived relation or fact over U.Work and U.RoleAssignment, not 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
• Motor_M1#DriveMotorRole:WaterPumpAssembly_A@installed-window
• 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 satisfies the sensor capability-fit condition. 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.

#Motor Assigned as Drive Motor

A water-pump assembly assigns a motor to the drive role for an installed window.

Motor_M1#DriveMotorRole:WaterPumpAssembly_A@installed-window
Work PumpingRun_2026-07-01 performedBy Motor_M1#DriveMotorRole:WaterPumpAssembly_A

The holder is the motor as a U.System. The role value is DriveMotorRole. The bounded context is the pump assembly or plant context that gives the role its meaning. The assignment does not say the motor is a part of the role; it says the motor bears that role in this system context. Torque capability, electrical supply, thermal limits, functional port claims, the pump's transformation-flow structure, and the dated pumping run remain neighboring claims under their own patterns.

#Software Deployment

A release train has a deployment method description with a step that states DeployerRole as a role-admission condition.

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 needed under [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 an enactment-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 enactment-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 role-admission 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 source text tries 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 a holder's capability instance, 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: an E.24.UK-admitted dependent durable U-kind name for holder-dependent capability instances. An individual U.Capability instance is a holder-dependent concrete governed object of a named U.System, recognized as that system's ability to perform a work family or produce a result class within a declared envelope, measure set, qualification window, and currentness condition. A statement, report row, certification, evidence relation, source-use relation, dashboard display, or currentness assessment about that instance is a neighboring governed record or relation, not the capability instance itself.

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, past work, evidence, or quality wording into the capability instance.

First useful move. Ask: who is the holder system, what work family or result class is the ability about, under what envelope, with what declared measures, during which qualification window, and which separate statement, evidence relation, source-use relation, or currentness assessment currently supports reliance on that capability?

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-side admission conditions, 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.
• If the current claim is one measured aspect with a declared scale, use U.Characteristic through C.16.P, A.19, and the current characteristic or scale owner.
• If the current claim is a composite quality family such as availability, resilience, security, or maintainability, use C.25 Q-Bundle.
• If the current claim is an architecture-characteristic starter head, project criteria row, architecture eval reading, or architecture-description concern, use C.32.HCS, C.32.ACS, C.32.ACE, or C.30 as applicable.

#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 can support a U.Capability instance when the holder, work family, envelope, measures, and currentness conditions are recoverable. The sentence itself is a statement about the capability instance. 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 retained as a dependent durable U-kind name under E.24.UK. A concrete U.Capability instance is the holder-dependent capability instance of a named U.System; its identity is grounded by the holder, work family or result class, envelope, measure set, qualification window, and currentness condition. The statement that asserts the ability, the evidence that supports reliance, and the fit predicate that tests work admission are separately governed records or relations rather than the U.Capability instance.

CapabilityUKindAdmissionDecision:
  CandidateSpelling: U.Capability
  Disposition: retained as dependent durable U-kind name
  E24Settlement: dependent capability instance under the named U.System holder settlement, governed here by A.2.2
  RootSubjectUKind: U.System holder whose ability is being stated
  DependentInstance: holder-dependent concrete U.Capability instance
  semanticArea: system ability, work admission, capability planning, and method threshold use
  ontologicalNeighborhood: U.System holder, U.RoleAssignment, U.Method, U.MethodDescription, U.WorkPlan, U.Work, U.Characteristic, Q-Bundle, architecture-characteristic row, evidence relation, source-use relation, currentness assessment, and capability-fit predicate
  IdentityGroundingOrRecognitionRule: holder plus work family or result class plus envelope plus measure set plus qualification window plus currentness condition
  admissibleUse: state or test that a named holder can perform a work family or produce a result class within declared bounds for planning, promise support, role-method-work admission, or architecture move feasibility
  nonUseBoundary: do not use U.Capability for statements, reports, evidence, source-use relations, currentness assessments, characteristics, Q-Bundles, architecture-characteristic rows, fit predicates, role assignments, method descriptions, work plans, or work occurrences
  NonUSubstitutionBoundary: statements, evidence, source-use relations, currentness assessments, Q-Bundles, characteristics, architecture-characteristic rows, and fit predicates do not become U.Capability

ConcreteCapabilityInstance:
  CapabilityHolderRef: U.System
  WorkFamilyOrResultClassRef:
  CapabilityEnvelope:
  CapabilityMeasureSet:
  QualificationWindow:
  CapabilityCurrentnessCondition:
  DependentInstancePolicy: dependent on holder identity and declared envelope/measure/window boundary

SupportAndUseReferencesAroundCapability:
  CapabilityStatementRefs?: governed episteme or publication records that describe the instance
  EvidenceRelationRefs?: governed evidence relations that support reliance
  SourceUseRelationRefs?: governed source-use relations used to justify or constrain the statement
  CurrentnessAssessmentRefs?: dated assessment relations evaluating the currentness condition
  CapabilityFitConditionRefs?: admission predicates or gate relations that test this instance for a use

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 holds: input range, environment, resources, configuration, system version, calibration state, staffing composition, access constraints, safety limits, or other current conditions.

CapabilityMeasureSet. The measures state achieved or required bounds with units, scales, tolerances, success predicates, reliability, throughput, latency, precision, defect rate, or other declared characteristics. A measure may cite a U.Characteristic, Q-Bundle slot, or architecture-characteristic criteria row as an input for a capability-fit check, but that characteristic, Q-Bundle, or architecture row does not become the capability.

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

CapabilityStatementRefs. A CapabilityStatement is a governed episteme or publication-side record that says a capability instance exists, describes its holder, envelope, measures, and window, or cites it for planning. It is not U.Capability, but it is still a governed record under its own episteme or publication pattern.

EvidenceRelationRefs and SourceUseRelationRefs. Evidence, tests, certifications, prior work summaries, simulations, audit records, standards, and model results can justify a capability statement through direct evidence or source-use relations. These are governed relations or records. They do not become the capability and do not become its holder.

CurrentnessAssessmentRefs. A currentness assessment is a dated assessment relation saying whether the capability instance remains usable under its qualification window and current conditions. It is not the capability instance, but it is still a governed assessment relation. CapabilityCurrentnessCondition states what must remain true; an assessment evaluates that condition.

CapabilityFitConditionRefs. A capability-fit condition is an admission predicate, threshold, or gate relation that tests a holder capability and any declared characteristic, Q-Bundle, or architecture-characteristic inputs against a current role, method step, work plan, work occurrence, bounded context, or gate need. It is a governed relation or predicate. Unless a separate E.24.UK admission is written, it is not a U.* kind.

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 instance. 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 instance:

ConcreteCapabilityInstance:
  holder: U.System
  canDo: WorkFamilyOrResultClass
  envelope: CapabilityEnvelope
  measures: CapabilityMeasureSet
  qualificationWindow: QualificationWindow
  currentnessCondition: CapabilityCurrentnessCondition

Separate supporting record:

CapabilityStatementRecord:
  describedCapabilityRef: ConcreteCapabilityInstance
  statementSourceRef:
  evidenceOrSourceUseRefs:
  currentnessAssessmentRefs?:

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 sentence form is a publication or statement about the capability instance. It 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, assert that a work occurrence happened, prove an architecture characteristic, or make the evidence relation into the capability.

#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
  holderCapabilityRef: A.2.2
  capabilityFitCondition: admission predicate over declared capability measures and any named characteristic, Q-Bundle, or architecture-characteristic inputs
  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 names the holder's capability instance within the envelope, measure set, and window;
• capability-fit condition tests whether that instance meets the current threshold or gate need;
• 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 instance perform the work. Do not treat a fit predicate, Q-Bundle, architecture-characteristic row, evidence relation, or currentness assessment as the capability instance.

#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 instance is separate; a statement or record may describe it:

ConcreteCapabilityInstance:
  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
  currentnessCondition: calibration and configuration remain inside the qualification window
SupportAndUseReferencesAroundCapability:
  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 satisfy the declared currentness condition; a benchmark report or model card is support for a statement about that instance.

#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 instance keeps the ability of the department visible and measurable; the management report describing it is a statement about that instance.

#Episteme Anti-Case

"ISO 26262 has safety capability" is not a capability statement about a holder-dependent capability instance. 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 instance, or lower reliance on a statement about it, 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, lowering the support or currentness assessment rather than becoming the capability;
• 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 object that changed. A stale calibration window lowers the capability currentness assessment and may lower reliance on the capability instance; 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. A stale report lowers a statement or evidence relation before it lowers the capability instance itself.

#Composite Capability

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

ConcreteCapabilityInstance:
  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 concrete capability instance is asserted for Cell_3, not for every part and not for the method description. Dependencies may be named, but the bounded capability claim is about 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 instance and fit predicate 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;
• U.Characteristic, scale row, coordinate, score, metric, indicator, or threshold;
• C.25 Q-Bundle, quality-family label, mechanism, status, or evidence slot;
• architecture-characteristic starter head, project criteria row, eval program, eval reading, selected-structure adequacy claim, or architecture-description concern;
• capability-fit predicate, gate, admission relation, or work-entry readiness record;
• 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 instance, a statement about it, or a fit check over it. They do not become the capability by adjacency. Name the neighboring value, record, relation, or predicate through its own governing pattern when that neighboring claim is current.

#A.2.2:End

#U.PromiseContent (Promise Content)

Type: Definitional promise-content episteme pattern Status: Stable

#Kind Settlement

U.PromiseContent is a dependent durable promised-outcome episteme under the episteme settlement. It is not a root beside U.Episteme, not a commitment, not work, and not a carrier.

#Use This When

Use this pattern when a project needs to state what is promised to a consumer before asking who is obligated, what work was done, which system exposes access, or how evidence will judge fulfilment.

Typical moments:

• an SLA, service catalog, product offer, public API promise, utility offer, or government service description says what a consumer may rely on;
• a team says "the service" but might mean promise content, provider organization, API, access point, delivery system, method, ticket, or performed work;
• a promise must be judged by acceptance criteria against work evidence, without turning the promise clause into the work or the system.

Primary EntityOfConcern. The EntityOfConcern is U.PromiseContent: a consumer-facing promise-content episteme that states promised outcome, access or eligibility, and acceptance criteria inside one bounded context.

First useful move. Write the promise content as a clause: what outcome is promised, who may use it, how access is described when relevant, and how fulfilment will be judged from work evidence. Then use U.Commitment only when an accountable subject is assigned to that content.

What goes wrong if missed. The word "service" starts naming provider, API, method, ticket, work, department, and promise at once. Teams then judge work against an implicit promise, treat access systems as obligations, or count performed work without knowing which promised outcome it was meant to satisfy.

What this buys. One consumer-facing promise-content episteme that can be linked to commitments, role assignments, access descriptions, work evidence, acceptance criteria, and outcome specs without collapsing those neighboring objects into one "service" bundle.

Not this pattern when. If the current EntityOfConcern is the accountable deontic relation, use A.2.8; if it is the performed delivery work, use A.15.1; if it is the access point or delivery system, use system and architecture patterns plus A.6.8 service wording repair; if it is contract-bundle unpacking, use A.6.C.

#Problem frame

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 one kernel meaning: a consumer-facing promise content clause. Any other “service” sense MUST be modeled explicitly as U.System, U.RoleAssignment or 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, and acts is handled as a precision-restoration lens in A.6.8 (serviceSituation(...)). Contract-talk unpacking and classification of "contract", "SLA", and "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 description or specification 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 description or specification is how you know what to do.

Lexical note (L-SERV and RPR-SERV)

The lexical forms service, service-level, service use, and service access (and the adjacent cluster service provider, server) are ambiguous across domains. In the kernel, U.PromiseContent is reserved for the consumer-facing promised-outcome statement.

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 trigger 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 or endpoint as the service hides the consumer-oriented promise (effect plus acceptance).
3. Process = Service. Mapping a procedure or Method (or a WorkPlan) to "service" confuses recipe or schedule with the external commitment.
4. Run = Service. Logging Work as "a service" erases the standard and 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 and access (how a consumer may request or use), and (iii) acceptance criteria (SLO-like or SLA-like targets) by which fulfillment is judged.

U.PromiseContent is promise content (U.Episteme), not a deontic commitment relation. One or more explicit U.Commitment objects (A.2.8) MAY reference a U.PromiseContent as payload for an accountable principal or 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 or Episteme, // the externally observable effect or value
  providerRole   : U.Role,             // role kind that may provide it (not a person or system)
  consumerRole?  : U.Role,             // optional role kind allowed to consume
  claimScope?    : U.ClaimScope,       // where the promise holds (G): operating conditions, populations, or locales
  accessSpec?    : U.MethodDescription,       // service access spec: request-facing interface and eligibility; not an access point system
  acceptanceSpec : U.Episteme,         // targets: SLO-like targets or acceptance targets such as quality, throughput, latency, or 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 or measured (unit + countingRule; see A.7:5.10)
  version?       : SemVer or 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 and 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 is promised in kind form and specification 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 or object after the work.

This is a controlled semantic precision restoration for the everyday metonymy "outcome" or "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 Delta anchors (affected referents plus pre-state and post-state anchors) on the declared state-plane (A.15.1:4.2 item 10). Evidence carriers and 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 and 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 limit).
• resultSpec corresponds to the result-as-promised facet: it states the post-work entity or 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 or state only, say result and link it to resultSpec. If it means the work episode(s) promised, say work as promised and link 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 older “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 or ScaleRef,        // pass, fail, or 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 and evidence plus the relevant Delta anchors (affected referents plus pre-state and post-state 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).
• Gamma_timePolicyRef keeps windowing explicit and non-retroactive (F.10 and 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, or endpoints are U.System (see A.6.8: service access point and service delivery system).
• Not a method or recipe: that is U.Method or U.MethodDescription.
• Not a run, incident, or 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, for example a request or 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 and 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 states the promise, Method describes, Work occurs and is evidenced.

#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 facet-recovery 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 and 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, or grade; computed)"]

  SC -->|"payload ref"| C
  C -->|"names accountable 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 the consumer-facing outcome and acceptance statement.
• The commitment names the accountable subject and it references the clause.
• The provider role assignment is the accountable subject that can act in a given Context and window.
• serviceSituation(...) (A.6.8) is a facet-recovery lens that names the common "service talk" participants (access spec, access point, delivery system, and 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 it, connect to it, visit it, restart it, or scale it, you are talking about a service access point (system facet), not the promised-outcome statement.

#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, work sequences, tickets) is mapped via Role, Method, and Work.

#Bias-Annotation

A.2.3 corrects service-bundle bias. A visible service name often bundles provider, access point, method, work, commitment, ticket, evidence, and promised outcome. The pattern recovers the promise-content episteme first, then links commitment, provider role assignment, access specification, work, evidence, acceptance, and outcome relations through their governing patterns.

It also corrects contract-form bias. A contract, SLA document, service catalog, API page, or public offer may publish promise content, but the publication carrier is not the promise-content episteme by itself and not the work that fulfils it.

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

The popular service diagrams (provider -> access -> use -> capability or activity) map to FPF as follows:

• Service provider role assignment → System#ServiceProviderRole:Context (U.RoleAssignment).

• Service Level Objective (SLO) and acceptance targets -> U.PromiseContent.acceptanceSpec (+ optional WorkPlan for windows).

• Service Level Agreement (SLA) (obligation-bearing source) -> U.Commitment referencing the relevant U.PromiseContent (and, where needed, its acceptance specs and evidence specs); use A.6.C Contract Bundle when packaging "the SLA" as a bundle of commitments, evidence specs, and publication carriers.

• SLA document or published terms -> U.SpeechAct (promise act or 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, or case whose state is changed) -> promisedOutcomeSpecRef.resultSpec.entityOfConcernRef (and the affected referents in delivery U.Work.Delta). "Ours vs theirs" (ownership or custody) is modeled as a role or relationship inside the Context (e.g., OwnerRole:..., CustomerRole:..., operated-by or owned-by), not as a Kernel-global property.

• Service Presence and Access -> accessSpec : MethodDescription (interface and 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 or Activity -> effects on the consumer side: either a Capability gained or used, or Work performed; do not reify as a new durable U-kind.

(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 or 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 or 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, or graded) against declared targets (SLO-style; any SLA deontics are represented via U.Commitment), and MUST declare Claim scope (G) where relevant (operating conditions, populations, locales). Every verdict cites an explicit Gamma_time window. If the acceptance criteria mention measurable characteristics (availability, latency, accuracy, cost, safety, etc.), each such characteristic MUST be introduced via the Characterization patterns (C.16 and C.25): an explicit U.Characteristic (with scale and unit plus measurement procedure and 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 or 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 and 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 and timespan. A U.Work that claims or 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 or server) in normative prose MUST be disambiguated per A.6.8 (RPR-SERV) and its lexical trigger L-SERV (E.10).

CC‑A2.3‑11 (No mereology). Do not place a promise content clause in PBS or SBS, or treat it as a part or component. Structural assemblies live in PBS and 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, and 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 and A.2.2). Scope-sensitive guards MUST use ScopeCoverage with explicit Gamma_time selectors.

CC-A2.3-14 (Bridges & CL). Cross-context mappings via Bridges keep F and G stable; CL penalties apply to R. A mapping MAY recommend narrowing the mapped Claim scope (G) as best practice (A.2.6 and 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 relation). 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, or 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 or 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-to-evidence relation 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 input, output, and Delta anchors 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 Gamma_time and claim scope) to the same Work facts and 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 or 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 or percentile of duration(Work) or of request-to-completion delta (declare definition).
• Availability or uptime: computed from Work and 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.

#Common Anti-Patterns and How to Avoid Them

• “The microservice is the service.” Rewrite to facet-explicit terms (A.6.8): the microservice is typically a service delivery system (U.System), a service access point (U.System), or both. Keep the consumer-facing promised-outcome statement in U.PromiseContent, and represent 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 promised outcome and acceptance statement judged by acceptanceSpec.

• “Our process is the service.” Process or 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 or 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 and 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 and 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 or 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 promise content, including local service labels that resolve to promise content, define 2-4 KPIs and the declared Work-based formulas (availability, lead-time, rejection rate, cost-to-serve), declare the Claim scope (G) and Gamma_time policy used for each KPI, and - when KPIs are numeric or comparable - define the underlying U.Characteristic plus measurement procedure and evidence (C.16 and 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 service", "technical service", or "internal service"), keep it in its own context and map to FPF Kinds via Bridges.
6. Tidy language. Apply A.6.8 (RPR-SERV) and L-SERV: ban unqualified "service" as a synonym for server, team, process, or ticket in normative prose; map them explicitly.

#Consequences

#Rationale

Everyday "service" language is useful because it compresses a whole service situation. FPF needs the opposite move when claims become normative: distinguish the promise-content episteme from provider systems, access points, commitments, methods, work, and evidence. U.PromiseContent gives the promised-outcome side one stable object while allowing A.6.8 to unpack the wider service situation when the surrounding facets matter.

The pattern keeps promise content in the episteme family because it is a clause or description that work can satisfy or fail to satisfy. It becomes obligation-bearing only through commitment, speech-act, contract-bundle unpacking, gate, or policy relations governed elsewhere.

#SoTA-Echoing

Service-management, product, utility, platform, and public-service practice all distinguish offers, providers, access channels, service levels, work execution, and evidence of fulfilment, even when everyday language calls all of them "the service". A.2.3 keeps that practical distinction in FPF by giving the consumer-facing promise clause its own episteme value and by returning provider, access, commitment, work, and evidence claims to their governing patterns.

Contract and SLA practice also distinguishes the promised content from the obligation-bearing act or agreement and from later performance evidence. FPF adapts that separation without importing a domain-specific service taxonomy: the promise content is reusable across IT, utilities, healthcare, public services, manufacturing support, and other bounded contexts.

#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 and assurance patterns (service KPIs, SLA dashboards); catalog and exposure patterns in domain contexts.

#Didactic quick cards (engineer‑manager ready)

• Promise content = Promise content. What we advertise and are judged by.
• Method description or specification = Recipe. How we usually do it (provider-internal).
• Work = Evidence. What actually happened and consumed resources.
• Provider and 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 and 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 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

Source text may name U.EvidenceRole or evidence-like role labels for a real need: 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 FPF repair is to model that use as an evidence-use relation, not 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 role-holder grammar from returning where an episteme-use relation is needed.

#Formal, Empirical, and Causal Evidence Uses

Source 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 role-like source 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

#Common Anti-Patterns and How to Avoid Them

#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

Evidence-use and status-use are kept as relation positions because an episteme can support, constrain, display, attest, or refresh different claims without becoming a work-facing role holder. This avoids multiplying role kinds for every publication, credential, dataset, proof, status display, source, and explanation use.

#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.
• Precision-restoration owners: When source wording says "evidence role", "status role", "standard role", or another role-shaped phrase around an episteme, use A.6.RSIR for relation-slot or role-like slot recovery and E.10.ARCH for ontology-first repair architecture.

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

#Kind Settlement

A.2.5 does not admit U.RoleStateGraph as a durable U-kind. The governed object is RoleStateRelation@BoundedContext: a selected context-local relation structure over U.Role, U.BoundedContext, role-state values, state predicates, state assertions, and work-admission relations. State-machine or graph notation is a mathematical or representation lens over that relation structure, not the object itself and not a new root beside U.Role.

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. 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. Enactment reification 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

Status: Stable Type: Ontic pattern

#Kind Settlement

U.ContextSlice and U.Scope are the durable USM values for scope work. U.ClaimScope, U.WorkScope, and U.PublicationScope are C.3-governed scope specializations under U.Scope, not independent root ontics. ContextSliceSet is the set-valued scope value over addressable U.ContextSlices, not an independent root kind. GammaTimePolicy, work-measure target sets, qualification-window policies, formality thresholds, detail values, abstraction-tier values, scope profiles, coverage metrics, guards, reports, and publication views remain policy values, characteristic values, non-U records, lenses, guard facets, or publication forms unless a direct governing pattern admits them. Dotted forms such as U.Mechanism.Intension name the intension slot or intension form governed by U.Mechanism and A.6.1; they do not admit a separate structural U-kind.

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 (intersection, SpanUnion, translate, widen, narrow, and refit) and uniform Cross-context handling through Bridge and CL.

Use this pattern when a project must decide where a claim holds, where a capability can deliver work, or where a publication surface is admissible across concrete context slices. What goes wrong if missed. Applicability, envelope, generality, validity, capability envelope, and publication applicability start acting like separate mechanisms; teams widen scope by wording, compose unsupported slices, or move claims across contexts without Bridge and CL loss.

What this buys. Scope becomes one set-valued mechanism over addressable U.ContextSlices, with carrier-specific specializations for claims, work, and publications and one algebra for intersection, SpanUnion, translation, widening, narrowing, and refit.

Vocabulary boundary. Use these scope names in live FPF wording:

• 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: intersection, SpanUnion, translate, widen, narrow, and refit. It is not a U.Characteristic and MUST NOT appear in any CharacteristicSpace.

Source words such as applicability, envelope, generality, and 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 and 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.)

#Problem frame - Purpose and 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 and episteme claims → Claim scope (G).
• System capability claims → 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 or 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 and operational clashed with Work and Run in A.15, producing governance ambiguity.

#Forces

#Solution - Overview

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, and 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”, or “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, ContextSliceSet, Part B Bridge and CL (U.Bridge, U.CongruenceLevel), and GammaTimePolicy.
• RangedValueKind (USM). ContextSliceSet (set-valued scope objects range over sets of addressable U.ContextSlice).
• SliceSet (USM). 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 subsetOf 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, and Publication scope objects inside a U.BoundedContext; coverage judgments are evaluated on explicit U.ContextSlice tuples (§6.1) and are not comparable or 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 and AdmissibilityConditions) or an extension USM ⊑⁺ USM′ (add new operators and slots). Any such specialisation SHALL (i) name its parent (USM), (ii) declare the morphism kind (⊑ vs ⊑⁺), (iii) preserve the same RangedValueKind and SlotKinds for inherited operators (no renaming), (iv) avoid adding new mandatory inputs to inherited signatures. It MAY narrow ValueKinds or 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 and version ids when current, environment selectors, Γ_time). Contexts MAY extend this tuple, for example with vocabulary ids or role-set 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 work-measure target sets (e.g., latency <= L, throughput >= T, tolerance <= epsilon) bound in guards (WG‑2).
• Declare inspection/recertification policies as qualification-window policies 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).

• Work-measure target set (mandatory). A set of measurable targets with units and tolerated ranges, evaluated on the JobSlice.
• Qualification-window policy (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, crosses Contexts, or both: 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 handle the outcome under an explicit 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 AbstractionTier (AT) as an optional facet; applicability is U.ClaimScope (G).