#Part A - Kernel Architecture Cluster

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

#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, 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 constructively recognized;
• architecture or selected-structure claims need the holon whose structure is being selected.

Primary EntityOfConcern. One exact U.Entity candidate whose actual construction may or may not satisfy the constructive recognition criterion for one already admitted holon kind.

Primary working reader. A practitioner or modeler who must decide whether part-whole, acting-system, or claim-bearing-holon reasoning is admissible for the exact entity under concern before relying on neighboring work, architecture, evidence, or publication claims.

First useful move. Name the exact U.Entity under concern. Then test whether its actual construction satisfies the A.1 holon-recognition criterion under an already admitted public holon kind. E.24.UK admits the public kind once at ontology level; A.1 does not repeat that decision for each candidate.

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 a selected bounded model-use relation organization, use A.1.1.
• If the current question is episteme identity, constitution, or neighboring-relation 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, 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, 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: which exact candidates satisfy the constructive recognition criterion for U.Holon or another already admitted public holon kind;
• acting eligibility: which recognized holons also satisfy the kind-specific criterion for the already admitted U.System kind;
• claim-bearing knowledge: which recognized holons also satisfy the kind-specific criterion for the already admitted U.Episteme kind.

Entity identity and world-side holon recognition have a context-independent base. Claim scope, effective reference scheme, and selected model-use structure can qualify a particular assertion or use, but none identifies the candidate, makes the constructive criterion true, or admits a public U-kind.

Other admitted holon kinds are not created by title, by filling one locally named slot, or by 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, and U.Discipline under C.20. BoundedModelUseStructure under A.1.1 is U.Structure, not a holon kind.

#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 filling creates false kinds. A system, episteme, holon, relation occurrence, or other value is given a new intrinsic kind merely because it fills one slot of a role-assignment, evidence, publication, description, or another direct relation.

#Forces

#Solution

Use A.1 to distinguish an exact referenceable entity from a candidate that satisfies the constructive holon criterion under an already admitted public 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.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. [E.24.UK](/generated/patterns/E.24.UK) owns public U-kind admission; A.1 owns recognition of exact candidates under the admitted holon kinds and the kind-specific patterns shown above. A selected U.Structure, including BoundedModelUseStructure, remains dependent relation organization rather than a holon kind.

#U.Entity

U.Entity is anything that can be individuated and referenced. It carries no part-whole, acting, claim-bearing, model-use, 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, reference, document, or another object under concern.

Do not apply holon aggregation, part-whole grounding, acting-system roles, or architecture claims to a bare U.Entity unless its actual construction satisfies the A.1 criterion for U.Holon or a kind-specific criterion for another already admitted public holon kind.

#U.Holon And Context-Independent Recognition

U.Holon is the broad part-whole EntityOfConcern: an exact U.Entity whose actual construction supports treatment as a whole with parts and as a possible part of a larger whole.

Keep ontology admission and candidate recognition separate. E.24.UK owns the one-time FPF decision that admits U.Holon and every other public holon kind. A.1 owns the constructive criterion by which an exact candidate is recognized under an already admitted kind. C.3.2 supplies three-valued discipline only for project-local kind membership; it does not own recognition under an admitted public holon kind. Candidate classification is a judgment about that exact entity; it is not a direct relation to a pattern edition, criterion episteme, evaluator, evidence set, or status value.

For one exact candidate, recover six distinct constructive components. Do not let one component stand in for another:

1. Exact candidate. Identify one exact U.Entity under its direct identity rule.
2. Exact constituents. Identify the entities claimed to constitute this candidate. Nearby entities, members of a set, sampled points, and arbitrary slices are not constituents by inclusion or wording.
3. Constructive part relations and assembly. Recover the exact obtaining part-relation occurrences under their direct patterns and the assembly by which those constituents compose this candidate. A list, diagram, or shared boundary does not establish those relations.
4. Reidentification rule. State the rule that distinguishes this whole and says which constituent, relation, boundary, or phase changes preserve or end its identity.
5. Composition-grounded whole-level characteristic. Recover at least one exact characteristic whose value or state is produced or sustained by the composition and is not attributable to one constituent alone.
6. Possible participation in a larger constructive assembly. Recover the candidate's actual boundary, interfaces, relevant characteristics, and identity-preservation conditions. Those facts must satisfy the applicability and compatibility conditions of at least one governed larger-assembly construction method or rule under which an admissible construction would include this candidate as a constituent while preserving its identity. One exact episteme may describe that method or state that rule and its conditions; the episteme does not create applicability, compatibility, or possibility.

Name the already admitted holon kind and its direct kind-specific pattern separately from those six components. The candidate satisfies the A.1 criterion when all six world-side components hold and any kind-specific condition is satisfied; it fails when a required component or condition does not hold. Satisfaction or failure does not vary with current evidence availability or evaluator access. Replacing a constituent or part-relation occurrence preserves the same holon only when the reidentification rule admits that change. An unassembled collection fails even when a project card calls it a holon.

Exact dated classification work belongs to A.15.1. When a reusable typed recognition-evaluation operation is current, A.6.1 governs its declared arguments and result plus the actual application bindings. The evaluation returns true when its governed inputs determine satisfaction, false when they determine failure, and unknown when missing evidence or an unavailable dependency prevents either determination. unknown is an evaluation result, not a third candidate state: the same candidate can satisfy or fail the criterion while the current evaluation remains unable to determine which.

When another use must inspect or cite the judgment, identify an optional C.2.1 classification-assertion or evaluation-result episteme whose exact EntityOfConcern is the candidate. Its claim content names the admitted kind, the A.1 criterion, the constituent and part-relation facts, reidentification rule, whole-level characteristic, candidate-side compatibility facts, exact construction-method-or-rule episteme, evaluation frame, and true | false | unknown judgment needed by that use. The assertion creates none of the candidate, constituents, part relations, assembly, characteristic, compatibility facts, method or rule, larger-assembly possibility, or holonhood.

Exact evidence and assurance relations support or warrant assertion claim content. G.11 separately governs whether the selected assertion edition is current. Receiving work separately decides whether to rely, decline to rely, defer, or reopen. B.2 owns the different question whether the existing whole is no longer the right EntityOfConcern for a receiving use. A.1 satisfaction, failure, or evaluation uncertainty supplies neither warrant for a B.2 claim nor grounds for selecting B.2.

In ordinary use, stop after naming the candidate, six constructive components, admitted kind, kind-specific condition, and resulting judgment needed by the work. Materialize a classification assertion only when a specific downstream task must inspect or cite that judgment.

#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 the admitted kind for dated 4D occurrence holons;
• 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. A project-local holon classification names its concrete C.3 U.Kind, the A.1 criterion, any kind-specific criterion, and the direct patterns for the construction facts it uses. A proposed public U.* holon kind first passes E.24.UK and gains one direct governing pattern. Neither route may rely on part-whole, architecture, role, work, evidence, or source-use claims before the candidate-side criterion is recoverable.

Candidate recognition is decided by the six candidate-side constructive components in A.1:4.2, not by agentivity, wording, evidence availability, or a B.2 whole-reidentification result. Grounding work selects the participating objects from the surrounding practice or world, fixes their boundaries, identifies constituents and exact part relations, recovers the assembly and reidentification rule, and tests the resulting whole-level characteristic and larger-assembly compatibility. Relations may arrange, constrain, assign, qualify, or describe constituents; those relations do not become constituents 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 is first recovered as a U.Method submethod rather than a method-description node, order relation, work-plan item, or work occurrence. A role value states what a holder is being under one assignment relation and role-taxonomy interpretation; assignment, state, capability, responsibility, permission, commitment, obligation, method participation, and role relation structure remain neighboring objects or relations rather than role parts.

#U.System

U.System is an acting physical or operational holon kind. It can participate in work-facing role assignments, capability relations, method enactment, mechanism realization, work occurrences, transformations, functioning relations, and responsibility-bearing claims when their direct patterns make those claims current.

Its kind-specific condition is acting eligibility: the recognized whole has an actual physical or operational organization through which it can causally participate in work or transformation while preserving its identity. Capability evidence or actual participation can support a classification assertion; a role assignment, work occurrence, or capability relation does not create the system by participation alone.

Keep those relations separate:

• A.2.1 governs the role-assignment occurrence whose HolderSystemSlot is filled by the system.
• A.2.2 governs capability claims about that system.
• A.3.1, A.3.2, and the mechanism family govern method, method description, and mechanism realization.
• A.15.1 governs performed work and the exact relation through which the system is attributed as performer.
• A.3.4 governs the bounded transformation; the exact direct subject-relation pattern governs the system's participation in it.
• Functioning, evidence, assurance, temporal, and dynamics claims remain with their direct patterns.

A.1 introduces no omnibus participation relation over references to all those occurrences. Listing them together in a worked case creates no additional world-side relation. If the selected organization among several direct relations changes an engineering decision, select that organization as U.Structure under A.22 and keep every constituent occurrence under its direct identity. Claim scope, effective reference scheme, and optional model-use structure qualify each dependent assertion only where its direct pattern makes them current.

#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 for episteme identity, EpistemeConstitutionRelation, and the direct empirical-grounding and edition relations declared there. Use the neighboring direct patterns for viewpoint, view, claim scope, bounded model use, evidence, publication, source use, carrier, and representation. A.1 only says that an episteme can be treated as a holon when part-whole treatment of the claim-bearing object is current.

A system in role decides, approves, performs work, promises, revises, authorizes, or bears responsibility with or about an episteme. The episteme does not perform those acts by itself.

#Recover Holon Delimitation And Boundary Crossing

When a claim concerns where a holon is delimited, recover the exact delimitation relation, criterion, or selected structure supplied by the direct holon, mereology, architecture, or domain pattern. Do not force an identity rule, membership relation, environment relation, selected structure, and boundary condition into one universal relation signature. Those objects have different kinds and predicates.

When one direct relation crosses that delimitation, keep the direct relation occurrence under its own pattern and use F.9 for the exact crossing or bridge claim. State the delimited holon, the direct crossing relation, direction, fit, loss, scope, and qualification window that are current for that use. A crossing classification does not replace the signal, control, measurement, transformation, source-use, publication-use, evidence-use, coupling, or other direct relation occurrence.

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 or establish candidate holonhood by label. Recover the current FPF claim first. Acting-agent and organization claims test the U.System criterion; data, document, and projected-content claims usually use U.Episteme, publication, source-use, evidence, or description patterns; process-holon wording uses work, method, work-plan, or transformation patterns; portal or traversal wording uses an access, crossing, policy, or evidence relation. A.1 recognizes only the exact candidate-side holon or system claim when its criterion is satisfied.

A Markov blanket is not a holon boundary by name. First recover whether the source names accepted local Markov dynamics, a mathematical or probabilistic lens, an exact holon-delimitation claim, a physical interface module or component, a functional element, a boundary description, or an agency-threshold claim. Apply the direct governing pattern. A.1 recognizes the exact holon candidate only when its constructive criterion is satisfied; it does not turn the neighboring delimitation claim into holonhood.

#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 the current claim: membership under A.14; collection-as-whole constructive grounding under C.13 and B.3.5 when assurance is current; whole-level characteristic under C.16; acting collective recognition under the U.System criterion plus A.15.1 work; or whole reidentification under B.2.

An acting collective U.System has a 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 governs constructive holon recognition. It does not replace exact part-relation patterns, C.13 constructional grounding, or E.24.UK public-kind admission.

Use A.14 and the direct part-relation patterns to identify the exact obtaining component, portion, aspect, phase, member, or other part relations. Use C.13 to show how those independently grounded constituents and relations assemble the candidate. If a C.13 trace is materialized, it is a C.2.1 episteme about that construction; writing or publishing the trace creates neither the constituents, the obtaining part relations, the assembly, nor the whole. Use B.3.5 only when a named assurance use needs grounding or warrant for a structural assertion.

Systems, epistemes, methods, dated work occurrences, and disciplines are admitted holon kinds under their direct patterns. C.13 may describe their construction only after those patterns supply exact parts and whole-forming relations for the candidate. A selected U.Structure, including BoundedModelUseStructure, organizes already identified relations for a use; selection or a diagram gives it no constituents, parthood, agency, holonhood, or B.2 transition.

FPF avoids unrestricted composition. A set of nearby objects, graph, diagram, role bundle, method algebra, work breakdown, or source table does not become a holon merely because it can be listed or represented as a whole. Several independently identified transformations likewise do not become parts of one composite transformation from shared timing, a changed referent, a method or work decomposition, or a C.13 trace. When the work requires positive transformation composition or transformation holonhood and no direct composition governor supplies the candidate whole, constituents, contribution, compatibility, and reidentification rule, retain the exact blocker and stop before A.1 classification.

#Slot Filling Does Not Create A Kind

A system that fills HolderSystemSlot of a role-assignment occurrence remains a system. An episteme that participates as the EntityOfConcern in an EpistemeConstitutionRelation remains an episteme. A system can participate in a transformation through an exact governed direct relation without becoming the changed holon's super-holon. A holon that participates as the EntityOfConcern of a structure-description episteme remains that holon rather than becoming the description.

The SlotSpec belongs to the direct relation declaration. Its SlotKind names the local participant slot; its ValueKind constrains admissible fillers. Filling that slot establishes neither a new intrinsic kind for the filler nor a new relation occurrence unless the direct obtaining predicate and identity rule are also satisfied. Use the direct governing pattern before introducing any durable kind name.

#Archetypal Grounding (Worked Cases)

#Pump As Acting System

Pump #37 is first an exact U.Entity. Its actual construction satisfies the A.1 criterion for the already admitted U.System kind:

• the casing, impeller, seal, motor, and flanges are exact constituent entities;
• exact fastening, enclosure, shaft-coupling, sealing, and connection occurrences constructively assemble those constituents as Pump #37 under their direct part-relation patterns;
• the installed-assembly reidentification rule distinguishes Pump #37 and permits specified maintenance replacements;
• pump-level flow, pressure, and operating characteristics arise from the composition rather than from one constituent;
• its actual boundary, inlet and outlet interfaces, load envelope, and identity-preservation conditions satisfy the applicability and compatibility conditions of the governed plant-installation method by which the pump can remain one constituent of a larger cooling-water system;
• E.24.UK already admits U.System, while A.1 supplies the common holon criterion and its U.System clause supplies acting eligibility.

Those world-side facts make the criterion true whether or not the current project has enough evidence to determine it. Classification work with adequate inputs can return true and support a separate C.2.1 assertion. If evidence or one dependency is unavailable, evaluation returns unknown; Pump #37 and its criterion satisfaction do not change. Replacing the seal preserves Pump #37 only when the reidentification rule admits that maintenance phase.

If instead an exact coupling, load-envelope, or boundary-interface fact violates a condition of the governed plant-installation method, the candidate fails the criterion even when the drawing and rule-description episteme are current. Governed evaluation returns false when that incompatibility is available to it and unknown when the needed input is unavailable; neither result changes the world-side failure. Renaming or republishing the cited criterion pattern changes its episteme designation, edition, or currentness, not Pump #37 or the candidate-side facts.

Separate direct relations then state that Pump #37 fills the holder-system slot of its cooling-water circulation role assignment, has a flow-rate capability envelope, is attributed as performer of inspection work WO-1842, and participates in the water-moving transformation. No omnibus participation or candidate-classification relation is added. The pump can have selected structures; its maintenance model may participate in a separately selected BoundedModelUseStructure, but that structure neither identifies the pump nor makes it a holon.

#Scientific Theory As Episteme Holon

Newtonian gravitation in one exact selected edition is first a C.2.1 U.Episteme candidate. Its actual claim-bearing constitution can satisfy the A.1 criterion for the already admitted U.Episteme kind:

• exact law, definition, derivation, diagram, exercise, and evidence-relation epistemes are the candidate constituents;
• exact claim-composition and episteme part relations organize those constituents as one governed claim-bearing whole;
• the selected-edition reidentification rule distinguishes the theory episteme and states which revisions preserve or end that identity;
• inferential and explanatory characteristics arise from the organized claim-bearing whole rather than from one constituent;
• its actual inferential interfaces, effective reference scheme, applicability conditions, and identity-preservation conditions satisfy the applicability and compatibility conditions of at least one governed method for composing it as a constituent of a larger explanatory or educational episteme;
• E.24.UK already admits U.Episteme, while C.2.1 supplies the kind-specific constitution condition.

A textbook publication can make this edition available, but the publication form and the episteme that describes the composition method do not create the theory's compatibility or holonhood. Classification work may evaluate the criterion and a separate C.2.1 assertion may state the result; evidence, warrant, edition currentness, receiving reliance, and any B.2 whole-reidentification question remain separately governed.

The theory does not teach itself, revise itself, or authorize laboratory work. A system under an exact role assignment may explain, revise, publish, compare, or use the episteme through separately governed work and relation occurrences.

#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", 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 to identify the bounded transformation from the exact changed referent, extent, boundary conditions, actual change facts, and continuity rule. Use the direct subject patterns for the lathe's participation, method, dated work, work-to-change facts, and evidence. Use A.14 or C.13 for part-whole only when an exact grounded part relation independently obtains.

#Stop Before A Whole Is Constructed

A pallet holding an unconnected pump, motor, baseframe, and manifold is a collection of exact entities. The list and physical proximity do not supply the fastening, coupling, enclosure, connection, assembly, or reidentification facts needed to recognize a skid holon. A construction drawing is an episteme about a possible assembly; it does not turn the collection into that assembly.

A selected BoundedModelUseStructure may organize model-applicability, delimitation, maintenance, and crossing relations for an engineering use. It remains dependent U.Structure; selecting it, naming it, or drawing it supplies no part relations, whole-level characteristic, acting eligibility, or B.2 whole reidentification.

Mounting, wiring, and fluid-connection changes may each be exact U.Transformation occurrences. Their participation in one work episode or one flow description does not identify a composite transformation. Without a direct transformation-composition governor, retain the separate changes and stop before transformation parthood, composite identity, or A.1 holon recognition. This stop does not say that the changes are atomic or have no finer parts.

#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, disciplines, research programs, and selected structures without making them all systems or holons.
• 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:

• Practitioners pay the cost of replacing umbrella uses of "system", "boundary", "interaction", "level", "emergence", and "collection" with exact governed claims.
• A reviewable holon-recognition claim states the exact constituents, construction, reidentification, larger-assembly compatibility, whole-level characteristic, admitted kind, and direct governing pattern on which it relies.
• 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, constructive part-whole recognition, acting eligibility, and claim-bearing. U.Entity gives the minimal referenceable object. U.Holon adds six separately recoverable constructive components: exact candidate, exact constituents, exact part relations and assembly, reidentification, a composition-grounded whole-level characteristic, and compatible possible participation in a governed larger assembly. U.System adds acting eligibility. U.Episteme adds claim-bearing structure without agentivity. U.Work and U.Discipline are holon-kind examples only through their governing patterns; BoundedModelUseStructure is selected U.Structure, not another holon kind.

The recognition base cannot depend on a prior context object without recursion. It begins with the exact candidate and world-side construction facts. Public-kind admission is the separate one-time E.24.UK decision. Classification work may evaluate the criterion, but its true | false | unknown result, a C.2.1 assertion, evidence, currentness, and receiving disposition neither participate in a candidate-side relation nor alter the candidate's identity.

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 the filling of one participant slot into a new kind. Architecture likewise starts from the exact holon recognized under an admitted kind whose selected structures matter; diagrams and structure descriptions remain epistemes.

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, selected structure, or source label become a holon.

#SoTA-Echoing

A.1 draws on current constructional-ontology, applied-foundational-ontology, and physics-side construction traditions for different questions. None of these sources admits an FPF kind, establishes a candidate's construction, or replaces the direct patterns that govern part relations, work, evidence, or publication.

For the Pump #37 and scientific-theory cases in A.1:5, the practical consequence is the same: recover the candidate and its subject-side construction first; use a governed method or rule only to test larger-assembly compatibility; keep evaluation, evidence, assertion, description, and publication as separately governed neighboring objects.

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.UK for one-time public U-kind admission, A.14 and C.13 for exact part relations and constructive assembly, and B.3.5 when Working-Model assurance grounding is current.
• Coordinates with: A.15.1 for dated classification work; A.6.1 for a current typed evaluation operation and actual bindings; C.2.1 for classification-assertion or evaluation-result episteme identity; A.10 and B.3 for evidence and warrant; G.11 for assertion-edition currentness; B.2 for the separate whole-reidentification question; A.1.1 for bounded model-use structure; A.22 for selected structure; C.30 for architecture; A.3.4 for transformation; C.20 for discipline; and E.10.ARCH for wording-use restoration.
• Used by: patterns that need an exact recognized holon, an already admitted holon kind, an acting system, a non-agentive episteme, a grounded part-whole claim, a collection-versus-collective distinction, a delimitation relation, or a boundary-crossing relation.

#A.1:End

#Bounded Model-Use Structure and DDD Bounded-Context Recovery

Type: Part A architectural ontology pattern Status: Stable Normativity: Normative unless marked informative

#Practitioner entry

Working reader and current decision. This pattern is for a domain architect, systems engineer, or service owner deciding whether several facts about one model must be treated together for the next engineering move. The reader starts from that decision—change scope, release scope, ownership boundary, integration boundary, or whether two uses belong together—not from a team name, repository, diagram, or the word context.

Governed object in plain language. A.1.1 governs the selected organization of where one exact model applies, how it is actually used in assigned Work, and whether concrete expressions still agree with it. The Tech name is BoundedModelUseStructure; the familiar Plain retrieval name is bounded context. It is a U.Structure, not a container for systems, teams, Work, documents, or publications.

First useful move — take the smallest branch.

1. Name one exact model edition and one exact place or thing about which it is used.
2. Ask what the present decision needs. If applicability alone answers it, recover ModelApplicabilityRelation and stop. If actual use is current, recover the exact role assignment, performed Work, and ModelUseRelation and stop. If maintained expression content is current, recover the fixed model content, fixed expression content, declared coherence predicate, and comparison scheme, then decide ModelExpressionCoherenceRelation and stop.
3. Recover the remaining direct relations only when their joint organization changes the decision. Select BoundedModelUseStructure only then.
4. Keep every boundary crossing separate. A proposed source, target, direction, required fit, permitted loss, and claim scope is useful planning content, but it is not an occurrence and cannot identify either endpoint structure.

First-minute success case. A press-control team must decide whether a controller-code change may be handled as a local code edit or must enter the independently governed release review together with model applicability and operating use.

1. PressControlModel-5 is the exact claim-bearing model edition, Press-3 is the use locus, and the model applies within SafetyControlClaimScope; this is one ModelApplicabilityRelation occurrence.
2. Exact F.6 performedUnderAssignment(PressOperationWork-91, OperatorAssignment-8) obtains. The assignment holder actually uses PressControlModel-5 during that Work concerning Press-3; this is one ModelUseRelation occurrence.
3. ControllerImplementsControlModelPredicate checks the fixed contents of PressControlModel-5 and PressControllerCode-17 under PlantControlReferenceScheme. It returns true, so one ModelExpressionCoherenceRelation occurrence obtains. The predicate is the test value, not the occurrence or an evaluation procedure.
4. Because independently governed PlantReleaseRule-3 needs model applicability, operating use, and fixed-content coherence together when each is material, select their organization and present those three facts jointly to the release review. This selection supplies the review's subject matter; it neither requires the review nor authorizes release.

This row names the selection-use frame reconstructed in the full assurance replay in section 5.1; the first-minute action does not require unpacking its A.22 identity proof. If the decision asked only whether the model applies to Press-3, stop after step 1. If PlantReleaseRule-3 were absent or did not require the three facts together, stop at the direct relations: the structure grants no review obligation. No crossing is asserted.

Three quick recognition situations.

Short glosses. A model episteme is one exact claim-bearing model edition. A model-use holon is one already admitted system or other concrete whole about which the model applies or is used; it is not a context container. Work (U.Work) is one exact dated doing, not its method, plan, or result. A claim scope (U.ClaimScope) is the set-valued boundary of context slices for one claim. A relation occurrence is a world-side relation actually obtaining under its predicate; an assertion, name, or diagram does not create it. A reference scheme is the interpretation basis for claim content. A structure here is a selected organization of already governed constituents, obtaining relations, applied constraints, and one exact selection-use frame; it is not another whole.

Adoption test. After applying A.1.1, name the exact organization that changes the present decision and the nearest overread that remains unavailable. If either is missing, stop at the direct relation or direct owner.

Names for retrieval. The Plain label is bounded context and the Tech label is BoundedModelUseStructure. F.18 and F.17 own their designation history, public row, lineage, and refresh evidence; A.1.1 keeps only the names needed to apply this pattern. Authors MUST NOT publish U.BoundedContext as a U-kind. The retained labels create neither a structure individual nor any applicability, use, coherence, or crossing occurrence.

#Problem frame

Use this when. Use this pattern when a current decision depends on the organization of three distinguishable facts about one exact model edition: where it applies, how it is actually used in assigned Work, and whether maintained expression content remains coherent with it. Physical location, team ownership, a document title, or the word context is not enough.

First useful move. State the decision, model, and use locus; recover only the direct relation that answers the question and stop when it suffices. Select the wider structure only when several already governed relations, applied constraints, and one exact selection-use frame together change the decision.

What goes wrong if missed. Systems, Work, epistemes, and publications are merged into a context-shaped proxy. One subsystem under two models is treated as one context by location, while one model used coherently across several loci is split by an implementation boundary. Local vocabulary, rules, units, status, or evidence use is also forced into a context object even when a direct semantic-locality owner answers the question.

What this buys. Actual participants retain their identities. Applicability, use, and fixed-content coherence remain inspectable direct relations; their decision-relevant organization can be selected as U.Structure; and ordinary semantic locality is returned to its exact value, relation, and governing pattern.

Not this pattern when. If only a term sense, role value, rule or invariant, admissible inference, unit or measurement basis, status, evidence use, claim scope, description, publication, or direct relation is current, use the A.1.1:4.4 triage and stop at that direct result. Do not select BoundedModelUseStructure unless the relation organization itself changes the decision.

#Problem

DDD bounded-context practice couples several real concerns: a model is defined and applicable within a boundary; actual systems in assigned roles use it; code and descriptions contain expressions of it; integration and maintenance work aims to keep those expressions consistent; and maps describe relationships among model uses. These are practical prompts to recover exact FPF claims, not evidence that maintenance caused coherence or that a described crossing obtains. Their objects are related, but they are not parts of one additional whole by that fact.

FPF needs this joint model-use relation organization selectable as U.Structure so it can serve as EntityOfConcern for comparison and maintenance work without becoming a heterogeneous holon, a description, or one universal semantic-locality reference.

#Forces

#Solution

Recover the Plain bounded context as one BoundedModelUseStructure, governed as a U.Structure. Identify it from one exact model episteme, exact already-admitted model-use holons, the selected organization of obtaining model-applicability, actual model-use, and fixed-content model-expression-coherence occurrences, exact applied constraint claims used by the selection judgment, and one exact selection-use frame. Each U.ClaimScope remains only a participant of its selected ModelApplicabilityRelation; a separate applied constraint claim may refer to that scope or its A.2.6 membership predicate. A bare scope, slice, membership outcome, boundary display, or carrier enters no A.22 discriminator. No boundary crossing participates in this identity. A later model edition has another C.2.1 episteme identity; continuity across it additionally requires exact EpistemeEditionRelation(earlierModelEpisteme, laterModelEpisteme) and the A.1.1 continuity rule.

#Select structure, not another holon

Use the four A.22 identity discriminators. The following sketch is a description of the selected organization, not the structure itself and not a relation signature:

BoundedModelUseStructure : U.Structure
  exact constituents:
    one selected model episteme
    exact admitted model-use holons
  exact selected obtaining relations:
    ModelApplicabilityRelation occurrences
    ModelUseRelation occurrences
    ModelExpressionCoherenceRelation occurrences
  exact applied constraint claims used by the selection judgment:
    one exact C.2.1 constraint proposition may refer to a U.ClaimScope or its A.2.6 membership predicate
    other exact applicability, coherence, release, or use-rule constraint propositions applied here
    no bare scope, slice, membership outcome, boundary display, or carrier episteme
  one named selection-use frame:
    exact question
    admissible action or stop
    nearest non-admissible overread

A selection-use frame is this exact three-part plain value; it is not a new kind, card, or record. A phrase such as current use, appropriate structure, or bounded-model-use frame does not fill it. Changing the question, admissible action, or nearest overread changes that identity discriminator.

The structure depends on its constituents and selected relation organization. It is not a holon whose parts are the substrate systems, Work, methods, or epistemes. Their identities, direct part relations, and any construction or whole-reidentification questions remain separately governed.

#Recover the direct relations

A.1.1 states each direct predicate and its occurrence-identity rule. An obtaining occurrence is an instance of a relation kind already admitted under U.Relation; its existence does not depend on a project deciding to expose it. A named receiving use may justify explicit individuation and reference under A.6.REL. A reusable RelationSignature episteme declares the participant SlotSpecs. An assertion or occurrence description may designate the actual participants by value or reference. Each table below is a readable presentation of one signature declaration. Its rows and cells are neither relation participants nor occurrences; they make neither the relation predicate true nor a relation occurrence obtain.

The two named temporal-extent ValueKinds below are local to A.1.1, not U-kinds. They can type a temporal extent stated in an assertion or occurrence description; they are not participant ValueKinds in either RelationSignature. For ModelApplicabilityRelation and ModelUseRelation, the direct obtaining history determines the maximal continuous extent used by the occurrence-identity rule. A filled assertion may state an open or closed extent, but that epistemic statement makes neither the relation predicate true nor a relation occurrence obtain and supplies no additional world-side participant.

For these two temporally varying relation kinds, continued obtaining extends the same open occurrence; a demonstrated gap ends it, and later resumption begins another occurrence. ModelExpressionCoherenceRelation instead has the participant-determined identity declared below: it has no temporal-extent discriminator. Revising an assertion changes the episteme, not any world-side occurrence.

ModelApplicabilityRelation. Its participants are one model episteme, one exact holon, and one declared claim scope. Its predicate asks whether that model applies to that holon over the exact U.ContextSlice values delimited by that scope. The model episteme's C.2.1 effective reference scheme supplies the interpretation basis; it is not a fourth participant.

Well-formedness constraint WF-A1.1-APP. ModelApplicabilityRelation(M,H,S) obtains exactly when S is the model-declared applicability scope or scopeSubset(S, modelDeclaredScope(M)), both scope expressions are interpreted under effectiveReferenceScheme(M), and the model's declared applicability conditions hold for H over every slice x for which member(x,S) is true. coversSet(S,T) applies only when T is an exact finite ContextSliceSet.

When S imports a local sense from another semantic setting, the interpretation branch exists exactly when the source and receiving F.17 SchemeSenseCell values are resolved and an F.9 Bridge obtains in the source-to-model orientation. Different schemes, shared spelling, or a Bridge Card does not establish that branch.

Well-formedness constraint WF-A1.1-APP-USE. A positive applicability assertion or structure selection that relies on the imported branch is admissible only when a separate current C.2.1 claim affirmatively states that the Bridge is suitable for this named scope-comparison use, direction, rule, and loss tolerance. For a use below the B.3 material-reliance threshold that makes no assurance claim, the same use must have an exact A.10 evidence-provenance graph relation with RelianceDisposition=pass. If an assurance claim is made or the threshold is met, a current positive B.3 assurance claim must carry the same bounded use and have a sufficient minimum reliance safety assurance record.

Use guidance. If the Bridge, bounded-use claim, or selected reliance branch is missing, return respectively missing claim-scope interpretation bridge, missing claim-scope interpretation use claim, or missing claim-scope interpretation reliance. These stops block the receiving assertion or selection; they do not make an otherwise obtaining Bridge false. Any membership judgment, operation application, assertion, or Work remains under A.2.6, A.6.1, C.2.1, or A.15.1.

The occurrence is reidentified from the actual identities of the model episteme, holon, and claim scope together with the derived maximal continuous ModelApplicabilityInterval. Repeating the model's effective scheme adds no independent discriminator. ModelUseRelation. Its participants are one exact role-assignment occurrence, one model episteme, one performed Work occurrence, and one exact use-locus holon. Its predicate is actual use of that model content by the assignment holder while that system performs the same Work concerning that holon.

Well-formedness constraint WF-A1.1-USE. ModelUseRelation(A,M,W,H) obtains exactly when F.6 performedUnderAssignment(W,A) obtains and HolderSystem(A) actually uses the content of M while performing W concerning H. The holder system is derived, not copied as a fifth participant. A method, if current, remains related to W under A.3.1.

The occurrence is reidentified from the four participant identities and the derived maximal continuous ModelUseInterval. A useful probe holds those participants fixed and asks whether a relevant model-content change can change how the Work is performed; availability or mention alone is not actual use. Scope delimitation is not another direct relation kind here. The U.ClaimScope participating in ModelApplicabilityRelation is a set-valued scope over U.ContextSlice; A.2.6 governs its primitive membership predicate. A membership assertion or an evaluation result is an episteme about that predicate. Neither creates a separate delimitation occurrence.

Local predicate-value declaration. ModelExpressionCoherencePredicate is an A.1.1-local ValueKind, not a U-kind and not an evaluation procedure. A by-value candidate belongs to this kind only when it declares (1) the ordered model-content and expression-content input meanings, (2) the exact comparison domain and local senses, (3) a Boolean truth condition, (4) the treatment of required congruence and permitted loss, and (5) every dependency whose absence makes application stop rather than return false. Two predicate values are identical exactly when those five by-value components are identical. A changed input meaning, domain, truth condition, congruence or loss rule, or dependency identifies another predicate value; a changed label, evaluator, evidence set, result episteme, representation, or publication does not. A label or procedure lacking the complete five-part declaration is not a member.

ModelExpressionCoherenceRelation. Its participants are one exact model episteme, one exact expression episteme, one by-value criterion admitted as ModelExpressionCoherencePredicate, and one exact U.ReferenceScheme used as the comparison basis.

Well-formedness constraint WF-A1.1-COH. ModelExpressionCoherenceRelation(M,E,P,R) obtains exactly when either (a) R equals the C.2.1 effective schemes of both epistemes, or (b) P resolves every differing source and receiving F.17 SchemeSenseCell pair and names an obtaining F.9 Bridge for each required correspondence; and, after that semantic branch is established, the fixed predicate value P returns true for the fixed claim contents of M and E under R. An unresolved cell, missing Bridge, shared spelling, common label, Bridge Card, or mere interpretability establishes no bridged branch.

The Bridge profile carries relation semantics only. Comparison direction, use-specific rule, permitted loss, and reliance belong to the separate bounded-use claim and reliance path.

Well-formedness constraint WF-A1.1-COH-USE. A receiving assertion or structure selection that relies on a bridged coherence occurrence is admissible only when a separate current C.2.1 claim affirmatively states that the Bridge is suitable for this fixed-content comparison use, direction, rule, and loss tolerance compatible with P. For a use below the B.3 material-reliance threshold that makes no assurance claim, the same use must have an exact A.10 evidence-provenance graph relation with RelianceDisposition=pass. If an assurance claim is made or the threshold is met, a current positive B.3 assurance claim must carry the same bounded use and have a sufficient minimum reliance safety assurance record.

Use guidance. Return missing model-expression interpretation bridge, missing model-expression interpretation use claim, or missing model-expression interpretation reliance for the corresponding missing condition. A use stop does not make the Bridge or predicate false and does not erase or reidentify an otherwise obtaining coherence occurrence. Comparison Work, an assertion episteme, and an A.22 selection use remain separate.

One occurrence is participant-determined by <M,E,P,R>; it has no temporal-extent discriminator and no later recurrence for the same tuple. Changed claim content identifies another episteme and tuple. Changed predicate value or comparison scheme likewise changes the tuple. Changed evidence, bounded-use claim, reliance result, card, publication, evaluator, or timestamp does not. Maintenance remains one separate dated Work individual admitted under U.Work, performed by an admitted system under an exact obtaining U.RoleAssignment. Its affected-referent, resource, parameter, premise, method-enactment, and operation-application facts use their direct relations or A.6.1 bindings. C.2.1 identifies any report or repaired episteme separately; only an exact A.15.PROD entity-inception claim may relate that episteme's first existence to the performed maintenance. An admitted system under an exact obtaining role assignment may separately perform evaluation Work. C.2.1 identifies any result episteme asserting whether the coherence predicate holds, and only its exact A.15.PROD inception basis may relate its first existence to that performed Work. Neither that result episteme nor its provenance is the coherence occurrence. Failed maintenance work remains actual work even when the changed episteme tuple has no obtaining coherence occurrence.

BoundedModelUseStructure selects obtaining participant-determined ModelExpressionCoherenceRelation occurrences. Maintenance methods and Work remain separate objects even when they change the receiving decision; if their organization must itself be selected, that is a distinct A.22 structure and does not enter this bounded-model-use identity.

Coherence-work stress cases. Coherence can obtain before any selected maintenance episode. Successful maintenance that leaves both episteme identities fixed leaves the same participant tuple; maintenance that changes expression claim content gives another C.2.1 episteme and a different tuple to evaluate. Failed maintenance may leave a changed expression episteme and a separately identified evaluation result while the new tuple has no obtaining coherence occurrence. Automated integration work and non-software maintenance use the same separation among fixed-content correspondence, work, result, evaluation, evidence, and provenance.

Occurrence-identity stress case. Exact F.6 performedUnderAssignment(InspectionWork-42, InspectorAssignment-17) obtains, and its holder Robot-7 uses DefectModel-3 concerning Pump-6 during that work. An observation at 10:00 supports continued obtaining of the same occurrence whose ModelUseInterval began at 09:00 and remains open; it does not create another occurrence. If model use demonstrably stops at 10:15 and resumes at 10:30 during the same work occurrence and assignment attribution, the resumption begins a second model-use occurrence. Correcting an assertion's timestamp without evidence of a world-side gap changes only that assertion.

Use guidance — unsupported crossing. First identify both endpoint BoundedModelUseStructure values without the crossing and state source, target, direction, required fit, permitted loss, and claim scope. Well-formedness constraint WF-A1.1-CROSS. A positive cross-structure member exists only when a current direct pattern supplies compatible endpoint SlotKinds, an obtaining crossing predicate, an occurrence-identity rule, and all four A.22 discriminators; the proposal, F.9 sense Bridge, label, diagram, or card supplies none of them. Otherwise preserve the six-part proposal, omit it from both endpoint identities and every positive cross-structure member, and return missing CROSS-LOCALITY-BRIDGE governor.

A.1.1 is the direct governing pattern for these three relation kinds. A.6.0 governs their RelationSignature epistemes, A.6.5 governs the SlotSpecs inside those declarations, and A.6.REL governs progressive explicit individuation. A.2.6 separately governs claim-scope membership. BoundedModelUseStructure is the selected organization of the resulting occurrences under those scope values; no context record copies their participants.

#Use the settled public relation names

The direct definitions, SlotSpecs, obtaining constraints, and occurrence-identity rules above govern the three relation kinds. A.1.1 uses only the settled Tech labels and their shortest Plain relation sentences:

F.18 and F.17 carry candidate-name history, public-row state, lineage, and refresh evidence. Those naming epistemes create neither a relation kind nor an obtaining occurrence, assertion, Work, interval, or structure. ModelExpressionCoherencePredicate remains an A.1.1-local five-part criterion ValueKind; it has no public F.17 row unless a later durable naming use independently reopens F.18.

#Identify continuity through model use

At one observation time, the structure has the four A.22 discriminators:

1. exact independently identified constituents—the selected model episteme and admitted model-use holons;
2. exact selected obtaining applicability, use, and coherence occurrences;
3. exact applied constraint claims used by this selection, each with a recoverable proposition and C.2.1 identity; a claim may refer to one U.ClaimScope or its membership predicate, but the bare scope, membership outcome, boundary display, or carrier is not this discriminator; and
4. one exact named selection-use frame containing its question, admissible action or stop, and nearest non-admissible overread.

No crossing or proposed six-part crossing record enters those discriminators.

At a later observation time, reidentify the same structure only when every continuing constituent is reidentified under its direct rule; any replacement model is connected by exact C.2.1 EpistemeEditionRelation and admitted by the declared continuity rule; every continuing relation occurrence retains its direct identity; every replacement occurrence is explicitly admitted; and all four A.22 discriminators remain the same under that rule.

The continuity rule therefore compares the exact constituents, selected occurrence organization, exact applied constraint claims, and the complete selection-use frame. A changed constraint proposition reopens the third discriminator; changing only a membership assertion, boundary rendering, carrier, or evidence about an unchanged constraint claim does not. A changed question/action/overread frame reopens structure identity even when every substrate and relation occurrence remains unchanged. A changed page, wording, rendering, carrier, description edition, or publication does not. File history, edition labels, publication order, a shared name, or membership in an edition collection establishes neither EpistemeEditionRelation nor bounded-model-use continuity; A.14 governs any separately selected collection of editions.

Missing evidence creates uncertainty about a continuity claim; it does not by itself end a world-side relation or structure. Any selected substrate holon may separately participate in a larger whole under A.14 and C.13; that is not parthood of BoundedModelUseStructure.

#Resolve semantic locality through direct values and relations

When the question is local meaning rather than joint model-use organization, recover the smallest direct result and stop:

For movement between local meanings, resolve the exact source and receiving F.17 sense cells and then apply F.9. An obtaining Bridge states correspondence between those readings; the separate bounded-use claim states direction, rule, and tolerance, and A.10 or B.3 governs reliance. The Bridge is not the rule, unit, status use, inference, or receiving action.

If a direct owner still asks for a generic U.BoundedContext or BoundedContextRef instead of the exact values above, do not fabricate that participant. Preserve the exact value or relation already recovered and stop at the owner's unresolved interface. The transfer is not complete merely because A.1.1 names a destination.

#Heterogeneous semantic-locality replays

Hospital operating-room replay. No context holon is created.

This replay selects no BoundedModelUseStructure unless one exact model's applicability, assigned-Work use, fixed-content coherence, applied constraints, and selection-use frame also become current.

Two further retained uses.

#Keep descriptions and publications separate

A bounded-context description is a U.Episteme. Under its C.2.1 declaration, the description's entityOfConcernRef designates the exact EntityOfConcern named by the description's claims. EntityOfConcernSlot is the SlotKind in that declaration; it does not itself point to the world-side object. A meta-description designates that description episteme through ordinary C.2.1 recursion.

When a description claim needs empirical grounding, recover one exact C.2.1 EpistemeEmpiricalGroundingRelation between the description episteme and the admitted grounding holon. GroundingHolonSlot is only the signature-local participant meaning in that relation's declaration; a groundingHolonRef in a card or description merely designates the participant and does not make the relation obtain. The selected structure cannot fill that participant because it is not a holon. Viewpoint, claim scope, effective reference scheme, publication use, rendering, and presentation carrier remain separately governed.

A stale description has another episteme edition or an obsolete currentness claim. Neither condition by itself changes the model-use structure or its world-side relations.

#Recover DDD context mapping by direct object

Start with three questions: what reusable way of mapping was used, what work actually happened, and what claim-bearing product resulted? Identify that product under C.2.1. Call the same episteme a view only after it passes one exact E.17.0 viewpoint-conformance test. Keep the relation structure it describes and every diagram, page, or publication separate.

Code/schema split. Start from the exact claim, not the source phrase. Claim-bearing source-code or schema content such as PressControllerCode-18 is a C.2.1 episteme with an exact EntityOfConcern and effective scheme. A repository, file, publication form, or presentation carrier that bears that content remains under its direct representation/publication/carrier pattern. A deployed controller, database, or software organization remains an actual system or selected structure under its direct owner. The phrase code base or database schema grants none of those identities and never supplies one universal kind.

Positive case: the fixed claims expressed by PressControllerCode-18 participate as the expression episteme in ModelExpressionCoherenceRelation. Near misses: PressControllerRepository-2 is only the repository or carrier being referred to, and DeployedPressDatabase-4 is the deployed database system or structure. Neither near miss may fill an episteme participant merely because source practice calls it a code base or schema.

This dispatch table is a reading aid for selecting the governing FPF object and pattern. Only that direct pattern supplies object identity, relation obtaining, or dependent-kind membership. If a separately current claim says that the candidate episteme first existed through the performed mapping Work, apply A.15.PROD only to that exact local inception claim. If an earlier episteme participates as source, use C.2.P to recover the exact source expression and route the source-use relation to its direct governor. Evaluation Work and any result episteme remain separate. None of those facts, and no product name, representation, rendering, publication occurrence, form, or carrier, grants U.View membership.

FPF Map remains the mapping-method head for mapping subjects to coordinates in a declared Space. The quoted DDD product name stays a retrieval cue; by itself it grants neither dependent U.View membership, the FPF Map reading, nor identity with the structure.

BoundedModelUseStructure and A.22's conditional cross-structure rule concern different structures. First identify every bounded model-use structure from its own model, admitted holons, three direct relation families—including each applicability occurrence's exact U.ClaimScope participant—exact applied constraint claims, and named frame. A scope or membership result is not copied into the constraint discriminator. Only then may a distinct A.22 structure select several such endpoints and independently governed obtaining crossings among them. Until those crossing occurrences and all four A.22 base discriminators exist, no member of that conditional specialization is asserted and its A.22-local label remains pending. Maintenance Work remains separate from both structures. A candidate context-mapping episteme may carry claims about a proposed crossing organization without designating an exact structure. Once the direct crossing and A.22 identity exist, a corresponding C.2.1 episteme may designate that exact cross-structure and its participants without becoming any of them. Only an explicit C.29 representation may show the structure or proposal; the episteme is a U.View only after exact E.17.0 conformance obtains.

#Preserve the lightweight path

Most local claims need no bounded model-use structure declaration. Name the exact current participant, semantic-locality value, role-assignment occurrence, or direct relation occurrence under its governing pattern and stop.

Select and expose BoundedModelUseStructure only when the joint organization of independently governed model applicability, actual model use, fixed-content model-expression coherence, exact applied constraint claims, and the named frame changes the next engineering move. Keep each claim scope solely in its applicability occurrence unless a distinct applied constraint proposition refers to it. If a crossing matters, open the separate A.22 cross-structure question only after its direct governor makes that exact crossing obtain between already identified endpoint structures; never add it to either endpoint identity. Recognize an episteme as U.View only after exact E.17.0 conformance. Publish that already recognized view under E.24.PUB only when a declared audience and use need it.

#Archetypal Grounding

#Full control-model assurance replay

The first-minute case in section 0 is enough for ordinary entry. This longer replay checks the ontology and stop conditions without turning them into the first-use path.

1. Applicability decision. ModelApplicabilityRelation obtains among model episteme PressControlModel-5, system Press-3, and claim scope SafetyControlClaimScope. C.2.1 fixes PlantControlReferenceScheme as the model episteme's effective scheme, so it supplies the interpretation basis without becoming a fourth participant. The derived ModelApplicabilityInterval remains open while the model's declared applicability conditions hold for Press-3 over the exact U.ContextSlice values admitted by member(slice, SafetyControlClaimScope) under that scheme.
2. Actual-use decision. Exact F.6 performedUnderAssignment(PressOperationWork-91, OperatorAssignment-8) obtains. The assignment holder is Operator-12 : U.System; that system actually uses PressControlModel-5 concerning Press-3 during the same PressOperationWork-91 : U.Work. Those four relation participants plus the derived maximal continuous ModelUseInterval reidentify one ModelUseRelation occurrence.
3. Scope boundary. Under the A.2.6 membership predicate, EmergencyStopContextSlice belongs to SafetyControlClaimScope. This membership claim explains part of the applicability boundary; it is not another relation occurrence selected into the structure.
4. Fixed-content coherence decision. ControllerImplementsControlModelPredicate is an admitted local predicate value. Its ordered inputs are the fixed claim contents of PressControlModel-5 and PressControllerCode-17; it returns true exactly when the code expresses every controller-command and feedback distinction required by the model, and false when a required distinction is missing. Both epistemes have PlantControlReferenceScheme as their C.2.1 effective scheme, so the relation-side comparison scheme is that same value and no Bridge is inferred. The predicate returns true for these participants, so their participant-determined ModelExpressionCoherenceRelation occurrence obtains before any selected maintenance episode.
5. Maintenance and change stay separate.
   • Work: Engineer-4 : U.System performs ControllerCoherenceWork-22 : U.Work under exact obtaining ControllerEngineerAssignment-7 : U.RoleAssignment; exact performedUnderAssignment(ControllerCoherenceWork-22, ControllerEngineerAssignment-7) and enactsMethod(ControllerCoherenceWork-22, ControllerAlignmentMethod-2) obtain.
   • Transformation and later episteme: A.3.4 independently identifies PressControllerCodeCarrierChange-24 : U.Transformation as the bounded change of continuing PressControllerCodeCarrier-6 : U.PresentationCarrier, using the exact edit boundary, before-and-after code-expression facts, and the carrier-continuity rule. Changed claim content identifies later episteme PressControllerCode-18 under C.2.1.
   • Stop: No current FPF relation says that ControllerCoherenceWork-22 caused or realized PressControllerCodeCarrierChange-24, so return missing work-to-change governor; temporal overlap and a shared code referent do not supply it. A.15.PROD remains closed for a claim that the Work first constituted PressControllerCode-18 until its exact entity-inception basis, including that missing link, is governed.
6. Evaluation and result stay separate.
   • Evaluation Work: Evaluator-2 : U.System performs CoherenceEvaluationWork-23 : U.Work under exact obtaining CoherenceEvaluatorAssignment-5 : U.RoleAssignment; exact performedUnderAssignment(CoherenceEvaluationWork-23, CoherenceEvaluatorAssignment-5) and enactsMethod(CoherenceEvaluationWork-23, CoherenceEvaluationMethod-4) obtain. State any needed operation application through its exact A.6.1 binding.
   • Result: C.2.1 separately identifies result episteme CoherenceEvaluation-23, which asserts whether the coherence predicate holds; only an exact A.15.PROD inception basis may relate that episteme's first existence to the evaluation Work. The result's assertion, evidence-use relation, and provenance remain distinct.
   • Next tuple: Because PressControllerCode-18 has different claim content, it forms another participant tuple with PressControlModel-5; predicate truth for that tuple decides whether another coherence occurrence obtains. Maintenance, method enactment, changed referent, evaluation, result, evidence, and provenance neither substitute for that truth nor enter the relation's participant set or identity.
7. Crossing stop. If a diagnostics crossing matters, first retain the independently identified source and target structures, then record direction, required fit, permitted loss, and claim scope. Current F.9 cannot turn that record into a relation over those structures. Omit it from any positive cross-structure member and return missing CROSS-LOCALITY-BRIDGE governor. The already governed endpoint relations remain available for their own selections.

Filled A.22 basis for the press-control structure. Its exact constituents are model episteme PressControlModel-5, use-locus system Press-3, and expression episteme PressControllerCode-17. Its selected occurrences are ModelApplicabilityRelation(PressControlModel-5, Press-3, SafetyControlClaimScope), ModelUseRelation(OperatorAssignment-8, PressControlModel-5, PressOperationWork-91, Press-3), and ModelExpressionCoherenceRelation(PressControlModel-5, PressControllerCode-17, ControllerImplementsControlModelPredicate, PlantControlReferenceScheme) as established in steps 1–4. OperatorAssignment-8 and PressOperationWork-91 remain actual participants used to establish the selected ModelUseRelation; they are not copied into the constituent plurality. Its exact applied constraint claims are PressSafetyScopeUseConstraintClaim, whose proposition says that every target slice used in the release judgment satisfies member(targetSlice, SafetyControlClaimScope); PressCommandFeedbackConstraintClaim, whose proposition says that the change preserves the model's command-versus-feedback distinction; and PlantJointReviewConstraintClaim, whose proposition says that, under independently governed PlantReleaseRule-3, all three selected occurrences are required inputs to the release review when each is material. SafetyControlClaimScope, any membership outcome, boundary rendering, and the claim carriers enter no discriminator by themselves. Its fourth discriminator is PressControlReleaseFrame from section 0: ask whether the change is code-only or jointly model/use/coherence-relevant; provide that joint subject matter to the release review; do not infer review or release authority from the structure. Missing any discriminator leaves the direct relations in place but blocks this structure selection.

The relation sentences above assert direct world-side occurrences; the scope sentence states an A.2.6 membership claim. Publishing either episteme does not create an occurrence or change scope membership. If the question is only whether the model applies to the press, stop at ModelApplicabilityRelation. Select BoundedModelUseStructure only when the selected applicability, operating-use, and expression-coherence occurrences plus the exact applied constraint claims and frame change the decision or Work plan.

One subsystem, one model. The press-control replay above is the filled case. The machine keeps its U.System identity; the selected structure uses the exact constituents, three obtaining relations, applied constraints, and PressControlReleaseFrame. Without that complete basis, stop at the direct relations. A diagram or later crossing is unnecessary for the positive selection.

One subsystem, two competing models. DeviceSubsystem-2 remains one system. Two structures are available only because each organization is independently complete:

An exact C.2.1 EpistemeEditionRelation may separately establish historical continuation; it does not merge simultaneous organizations. Near miss: if either side lacks its coherence occurrence, an applied constraint, or its complete frame, that side has useful applicability and use facts but no selected BoundedModelUseStructure yet.

One model, two use loci. ClinicalTerminologyModel-7 participates in two independently complete non-software structures:

Across these five filled structures, each assignment occurrence and dated Work stays only in its selected ModelUseRelation and in the evidence establishing that occurrence. Changing either one reopens that relation and therefore the selected-occurrence discriminator; it is not also an independent constituent replacement. One spanning structure is available only when one exact constituent plurality, relation-occurrence organization, applied-constraint set, and selection-use frame genuinely spans both uses. Shared model identity alone neither merges nor splits them. Near miss: exact diagnosis and billing Work plus a shared model, without one side's coherence occurrence or filled frame, supports only the direct facts on that side.

Published classification model. A NAICS publication remains an episteme. Exact F.6 performedUnderAssignment(ClassificationWork-4, ClassificationAssignment-3) and actual use of that model content concerning an organization supply the use branch. A positive NAICSClassificationModelUseStructure additionally needs exact applicability with ClassificationClaimScope as that relation's scope participant, fixed-content coherence with the classification expression, exact applied constraint claims stating which edition and classification distinctions the judgment must preserve, and NAICSClassificationFrame: ask which NAICS edition and distinctions govern this classification; use the complete organization for the classification claim; do not infer that publication makes the model used, that a Conformist label creates a crossing, or that NAICS is a system part. The bare scope or one membership result is not an applied constraint. Without the complete basis, stop at publication availability or the direct relation that actually obtains.

When a proposed directional dependency is called Conformist, retain its source, target, direction, required fit, permitted loss, and claim scope. Return missing CROSS-LOCALITY-BRIDGE governor until a compatible direct relation exists; the label does not create or identify the crossing. Stale description. An already recognized Context Map view is six months old while the same already governed applicability, actual-use, and model-expression-coherence relations continue. Its currentness claim can become obsolete; revising the U.View episteme or publishing another rendering changes those epistemic and publication objects only. The structures remain until their direct relation organization changes.

Context-mapping assurance case. This case tests the heavier method, product, view, and publication boundaries after the ordinary entry path has succeeded.

1. Method and Work. Exact F.6 performedUnderAssignment(ContextMappingWork-14, ArchitectureAssignment-6) obtains, and the assignment holder is Architect-9 : U.System. Exact enactsMethod(ContextMappingWork-14, ContextMappingMethod-3) obtains for ContextMappingMethod-3 : U.Method. The repeatable method and this dated ContextMappingWork-14 : U.Work remain different objects.
2. Candidate product. C.2.1 independently identifies episteme ContextRelationsAnalysis-8. Its EntityOfConcern is the six-part proposed crossing organization: source, target, direction, required fit, permitted loss, and claim scope. The episteme is not the proposed organization.
3. Current stop. No independent direct governor currently makes the proposed crossing obtain. A.22 therefore lacks the relation-occurrence discriminator needed for base identity, and the candidate episteme does not designate an exact member of the conditional crossing-analysis specialization. Stop at the proposed organization.
4. Later positive route. Only if a future direct governor admits that exact crossing and all four A.22 discriminators are recovered may a corresponding C.2.1 episteme designate the resulting exact structure. Changing the EntityOfConcern remains subject to C.2.1 episteme identity.
5. Source use and inception. If a current claim says ContextRelationsAnalysis-8 first existed through the mapping Work, A.15.PROD governs only that exact local inception claim. If source episteme ContextNotes-7 participates, C.2.P recovers its exact source expression and routes the source-use relation to its direct governor.
6. View evaluation. Reviewer-6 : U.System separately performs ContextViewConformanceEvaluationWork-15 : U.Work under exact obtaining ContextViewReviewerAssignment-10 : U.RoleAssignment; exact performedUnderAssignment(ContextViewConformanceEvaluationWork-15, ContextViewReviewerAssignment-10) and enactsMethod(ContextViewConformanceEvaluationWork-15, ContextViewConformanceEvaluationMethod-5) obtain. Any result episteme and any A.15.PROD inception claim about that result remain separate. ContextRelationsAnalysis-8 becomes a U.View only when exact EpistemeViewpointConformanceRelation(ContextRelationsAnalysis-8, ContextMappingViewpoint-4) obtains under E.17.0.
7. Representation and publication stop. The product name, mapping method, performed Work, source use, evaluation result, representation, rendering, publication occurrence, form, and carrier grant neither crossing-structure identity nor U.View membership and remain under their direct patterns.

#Bias-Annotation

This pattern has a DDD lineage bias because bounded context is the source term. Outside software, use A.1.1 only when the domain has one claim-bearing model edition, explicit applicability, actual use in assigned Work, fixed-content expression coherence, and a present decision changed by their joint organization. Industrial control, clinical or billing terminology, and published classifications can meet that test through different direct governors; a familiar context label cannot.

It has a structure-selection bias. The lightweight stop rule prevents mere local terminology, model mention, or implementation and organizational partition from becoming a structure without the required model-use relation organization.

It also has a model-coherence bias. Actual systems, work, methods, transformations, epistemes, and role assignments keep their own identities and can remain the referents designated by receiving epistemes when the joint relation organization is not the subject of the receiving use.

#Conformance Checklist

1. A positive BoundedModelUseStructure exposes all four A.22 discriminators: exact constituents, exact selected obtaining applicability/use/coherence occurrences, exact applied constraints, and one named question/action/overread selection-use frame.
2. The three direct relation declarations satisfy WF-A1.1-APP, WF-A1.1-USE, and WF-A1.1-COH; any imported-sense receiving use additionally satisfies WF-A1.1-APP-USE or WF-A1.1-COH-USE. Missing conditions return the named stop rather than a positive assertion.
3. Every ModelExpressionCoherencePredicate value satisfies the local five-part membership and value-identity rule. Every ModelExpressionCoherenceRelation occurrence is participant-determined by <model episteme, expression episteme, predicate value, comparison scheme> and has no interval discriminator.
4. BoundedModelUseStructure is governed as U.Structure; no context holon, context parthood, meta-holon transition, crossing, description, or publication enters its identity.
5. Reidentification compares all four discriminators and then applies A.1.1:4.3. A changed applied constraint or changed question/action/overread frame reopens identity even when constituents and relation occurrences are unchanged; a changed page, graph, rendering, or publication does not.
6. Semantic locality follows the direct-value triage in A.1.1:4.4. A local rule, inference, unit, evidence use, or status use remains at its exact direct owner; a broad label or unrepaired generic-context field cannot manufacture the missing participant.
7. A description episteme designates its exact EntityOfConcern under C.2.1. Empirical grounding requires one exact EpistemeEmpiricalGroundingRelation; a reference field, structure, view, or publication does not make it obtain.
8. DDD Context Mapping is recovered as method, dated Work, claim-bearing product, proposed or obtaining crossing organization, view conformance, representation, and publication under their separate owners. WF-A1.1-CROSS blocks a positive cross-structure member while the direct crossing governor or an A.22 discriminator is missing.
9. A code/schema cue is classified from the exact claim as claim-bearing episteme content, repository/file/form/carrier, or deployed system/structure; the cue itself supplies no common kind.
10. Two model uses over one subsystem yield two structures only when each independently supplies all three obtaining relation families, applied constraints, and its exact selection-use frame. Missing coherence or another discriminator leaves that side at its direct relations.
11. The structure is omitted when its joint organization changes no receiving decision. The reader can name both the admissible action and the nearest overread; otherwise the reader stops at the direct relation or direct owner.

#Common Anti-Patterns and How to Avoid Them

#Consequences

Benefits. Teams can compare model-use boundaries without inventing an enclosing whole. Competing models over one subsystem and one model across several loci become expressible through complete structure bases. Local vocabulary, rules, inferences, units, evidence use, and status use remain recoverable through direct owners rather than a context proxy.

Costs. A load-bearing structure claim must recover three direct relation families, exact applied constraints, and one question/action/overread frame. Semantic transfer sometimes stops at a direct owner that still cannot express the claim without a generic context field; that stop is preferable to inventing a participant or claiming false parity.

Limits. A.1.1 does not decide model truth, role assignment, rule validity, measurement, status, evidence, claim-scope membership, reference-scheme construction, system parthood, Work performance, release authority, or publication currentness. It selects only the bounded model-use organization after those direct claims are available.

#Rationale

The selected object must survive two decisive tests. One subsystem under two models needs two bounded contexts without duplicating the subsystem. One model coherently used across several loci may need one bounded context without pretending those loci are parts of another whole. A dependent U.Structure over exact relations passes both tests.

The practical DDD lesson retained here is that boundaries matter because model applicability, actual use, expression consistency, and relationships can change engineering decisions. FPF does not copy that sentence as one ontology: it separates participant-determined fixed-content coherence from maintenance Work, identifies each bounded model-use structure without crossings, and routes any independently governed crossing into a distinct A.22 structure over already identified endpoints.

#SoTA-Echoing

The source line is not one settled ontology. The 2015 reference defines a bounded context as a description of a boundary. The January 2026 worked case also uses the term for an actual system part and for use of the published NAICS model. FPF keeps those three readings distinct instead of choosing one of them as a universal context object.

Scoped FPF synthesis hypothesis and defeaters. This edition hypothesizes that, for the bounded uses declared here, the decision-relevant organization is one BoundedModelUseStructure over exactly the three direct relation kinds ModelApplicabilityRelation, ModelUseRelation, and ModelExpressionCoherenceRelation, its exact model-use substrate, exact applied constraint claims, and named frame. Each claim scope remains only the applicability-relation participant unless a distinct applied constraint proposition refers to it. Crossings belong only to a distinct A.22 structure over already identified bounded model-use structures. The hypothesis is usable only while each direct relation has coherent participant meanings, an obtaining rule, and an occurrence-identity rule, each applied constraint proposition is recoverable, and selecting their joint organization changes a concrete practitioner decision.

Fail this edition for the affected case, or reopen only the affected part of the synthesis, when:

1. any one of the three direct relations lacks coherent participant meanings, a coherent obtaining rule, or a coherent occurrence-identity rule;
2. a DDD case needs a materially different relation organization rather than this three-relation organization; or
3. selecting the joint organization changes no practitioner decision compared with stopping at the direct relations.

The external sources therefore change recognition and the tests applied to the working problem. Current FPF direct governors and the scoped, defeasible synthesis above supply the normative Solution. Constructional ontology tests a construction claim; it neither chooses the FPF kind nor proves the no-holon conclusion by citation.

#Relations

• A.1 governs constructive recognition of exact candidates under already admitted holon kinds and its locally declared U.System/U.Episteme distinctions. Direct identity patterns govern candidate identity; E.24.UK governs public-kind admission; A.14 and direct part-relation patterns govern parthood; C.13 governs constructive assembly. A.1 does not supply those decisions by itself.
• A.22 governs base U.Structure identity through exact constituents, selected obtaining relations, applied constraints, and one named selection-use frame. It also governs the conditional cross-structure question after a direct crossing governor exists.
• C.2.1 governs model, expression, rule, inference, and description episteme identity, effective reference schemes, exact EntityOfConcern and ClaimGraph content, EpistemeEditionRelation, and empirical grounding. It also identifies the separate bounded-use claim about an F.9 Bridge.
• A.2.6 governs U.ClaimScope, U.ContextSlice, and membership. C.16 governs measurement bases, readings, scales, units, and direct comparability. A.2.4 and A.10 govern evidence use; F.10 governs status family and status use; B.3 governs assurance.
• A.2, A.2.1, and A.2.7 govern role taxonomy, role assignment, and role-relation structure in model-use loci.
• A.3.1, A.15.1, and E.18 govern Context Mapping method, performed mapping Work, and transformation-flow structures. A.15.PROD enters only for a separately needed local entity-inception claim.
• F.17 and F.18 govern sense cells, durable public labels, candidate-name history, public rows, lineage, and name refresh. A.1.1 consumes the settled names without copying their dossiers.
• F.9 governs an obtaining Bridge between exact F.17 SchemeSenseCell values. A Bridge carries relation semantics, not a receiving-use decision or a structure-to-structure crossing. A separate C.2.1 claim states bounded suitability; A.10 or B.3 governs reliance.
• E.17.0, E.24.PUB, and C.29 separately govern view conformance, publication occurrence and availability, representation, rendering, form, and carrier.
• C.2.P recovers an exact source expression and routes any source-use relation to its direct governor.
• A.6.0 and A.6.5 govern the RelationSignature and SlotSpecs declared here; A.6.REL governs progressive explicit individuation after the direct relation kind, obtaining condition, and occurrence-identity rule exist.

#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 - System Role Assignment

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

#Use This When

Plain name. System role assignment.

Use this pattern when another claim must rely on which admitted U.System holds which enactment-facing U.Role, under which role vocabulary and interpretation scheme, during which assignment window.

Typical moments:

• a method description names InspectorRole, but the current holder and assignment window are still unstated;
• a performed-work attribution is needed: one exact dated Work occurrence W and one exact assignment RA participate in performedUnderAssignment(W, RA), the direct relation governed by F.6; the actual performer is the admitted holder System S = RA.HolderSystemSlot, and a separate assertion may designate W and RA;
• the same system receives the same role during two separate assignment episodes;
• a DDD-style model-use organization changes the interpretation of an otherwise identical role assignment;
• a constituting decision or installation relation may establish a specialized assignment occurrence;
• a roster entry, configuration line, observation, or evidence relation may support an assignment claim without becoming an assignment slot.

Primary EntityOfConcern. The EntityOfConcern is one obtaining U.RoleAssignment relation occurrence. Its four required actual participants are an admitted U.System holder, one U.Role value, the role-taxonomy episteme, and the effective U.ReferenceScheme under which that value is interpreted. The occurrence has a maximal continuous temporal extent determined by uninterrupted obtaining; an assignment assertion or occurrence description may state the currently known extent as an AssignmentInterval.

Primary working reader. The first reader is an engineer-manager, analyst, method author, or FPF author who must make role admission or work attribution inspectable without turning role, capability, method, performed work, evidence, or publication into one assignment relation occurrence.

First useful move. Write a readable assignment assertion naming the four required participants and the assignment episode being claimed. State the currently known temporal extent separately. Explicitly individuate the relation occurrence only when a receiving claim must distinguish this assignment episode from another rather than merely recognize that the direct relation obtains.

What goes wrong if missed. A role label is mistaken for an assignment, repeated episodes collapse into one timeless relation, or a database row is treated as what makes the assignment obtain. Work may then be attributed to the wrong holder or assignment episode, while evidence, capability, and method claims become hidden fields of the assignment.

What this buys. Assignment identity becomes stable enough for method admission, role-state checking, and work attribution while ordinary prose remains lightweight. The assignment relation has one exact identity rule; all support, decision, capability, method, work, evidence, and publication claims keep their direct governing patterns.

Not this pattern when.

• Use A.2 for role-value interpretation and the role taxonomy itself.
• Use A.2.2 for holder capability, A.2.5 for role state, and A.2.7 for selected relations among role values.
• Use A.3.1, A.3.2, and A.15 for method and role-admission conditions.
• Use A.15.1 and F.6 for performed work and its attribution through an assignment.
• Use the direct decision, responsibility, commitment, evidence, reliance, provenance, publication, external-rule, or currentness pattern when that relation is current.
• Use A.6.5 when an external relation notation labels a participant role and the current task is to recover its exact SlotKind and ValueKind.

#Problem Frame

A role value does not assign itself. InspectorRole may be understood under a role taxonomy, yet no robot, person, or service holds it until an assignment relation obtains. Conversely, the same system can hold several roles without changing system identity, and the same holder-role pair can enter several assignment episodes.

An admitted holder may be a person or another kind of U.System. Holding the role does not by itself establish consciousness, intention, legal or ethical accountability, permission, or gate passage; each stronger claim needs its direct governing pattern.

Role meaning is local to a role-taxonomy episteme and effective reference scheme. Assignment locality therefore needs those four actual relation participants directly, not a mandatory U.BoundedContext. When an actual DDD-style model-use organization changes one receiving interpretation, the receiving assertion or work use may designate the selected BoundedModelUseStructure; the structure is not an optional participant of generic U.RoleAssignment.

Assignment is also not performed work. A current assignment may exist before any work occurs. When work does occur, the admitted holder System S = RA.HolderSystemSlot performs exact Work W under exact assignment RA; F.6 owns the direct performedUnderAssignment(W, RA) relation. Capability, role state, method admission, responsibility, assignment decisions, and evidence remain separate relations with their own obtaining and currentness conditions.

#Problem

Without this pattern:

1. a role name is used as if it identified a holder and assignment episode;
2. role value, taxonomy episteme, interpretation scheme, holder, and time are compressed into one label;
3. two assignments with the same holder and role but disjoint windows become one occurrence;
4. assignment is treated as proof of capability, method admission, role state, performed work, or authorization;
5. a constituting assignment decision or installation relation and epistemic evidence or provenance collapse into one untyped justification field;
6. an optional DDD model-use structure is made mandatory or identity-bearing without showing that it changes interpretation.

#Forces

#Solution

State the direct assignment in readable prose first. When another claim needs reusable participant typing or occurrence identity, use the RelationSignature for U.RoleAssignment governed here and declared through A.6.0 and A.6.5. The signature is an episteme about the relation kind; it is not the world-side assignment occurrence. Its SlotSpecs are:

The four SlotSpecs declare all participant meanings of generic U.RoleAssignment. No SlotSpec is declared for the occurrence's temporal extent or for a selected model-use structure used only to qualify a receiving interpretation.

AssignmentInterval is a local content ValueKind for an assignment assertion or relation-occurrence description, not a U-kind and not the ValueKind of a relation-participant SlotSpec. An assignmentInterval field states the currently known temporal extent through a temporal reference, a start boundary, an end boundary or explicit open end, and the continuity claim used to recognize one uninterrupted assignment episode. The world-side occurrence has that temporal extent under its direct identity rule. The field describes the extent and does not make the relation obtain. A shift label is sufficient only when those temporal facts can be resolved. C.27.TA governs fuller temporal-aspect description when the temporal reference or interval itself becomes a relied-on object.

U.RoleAssignment obtains when the admitted system holds the role value, interpreted by the named role-taxonomy episteme under the effective reference scheme, throughout one continuous assignment episode. An assignment assertion is a U.Episteme claiming that this relation obtains. A roster entry or configuration line may express that assertion, and a publication may expose it; evidence may support relying on it. None of those epistemic or representation-side objects makes the world-side relation obtain merely by existing.

#Relation-Occurrence Identity

Do not replace the identity rule with a tuple key. One generic U.RoleAssignment occurrence begins when the assignment predicate starts obtaining for one fixed holder system, role value, role-taxonomy episteme, and effective reference scheme. It continues while that predicate obtains without interruption for those same four actual participants. It ends when the predicate ceases to obtain or one of those participants changes. A later resumption starts another occurrence.

An assignment assertion or occurrence description may carry an AssignmentInterval stating the currently known temporal extent of that occurrence. [start, open] can designate the current episode before its end is known. Recording the end boundary later refines the description of the same occurrence when obtaining was continuous. A gap in available evidence remains unknown and does not by itself split the occurrence. A demonstrated period of non-assignment ends the occurrence; a later resumption begins another. Two descriptions refer to the same occurrence only when they resolve to the same four participants and to temporal information belonging to that one uninterrupted period.

A selected model-use structure does not enter generic assignment identity. A genuinely structure-dependent relation species requires its own direct pattern, a required identity-bearing structure participant, a stronger predicate, and an explicit occurrence-identity rule.

#Filling the Declared Slots

Resolve HolderSystemSlot through U.EntityRef and check that its referent is an admitted U.System. Embed RoleValueSlot and EffectiveReferenceSchemeSlot by value. Resolve RoleTaxonomyEpistemeSlot through U.EpistemeRef to the exact episteme edition used for interpretation. If a receiving assertion or work use depends on a selected BoundedModelUseStructure, designate that structure in the receiving episteme or use relation under its direct governor.

Those four required designations correspond to the actual participants under the declared participant meanings. State the currently known temporal extent separately as assignmentInterval in the assertion or occurrence description. Assignment decision, responsibility, evidence, provenance, installation work, role state, capability, performed work, selected model-use structure, and publication remain separate objects or relation occurrences under their own governing patterns.

#Well-Formedness Predicates

RA-1 HolderAdmission:
  the U.EntityRef filling HolderSystemSlot resolves to an admitted U.System.

RA-2 RoleInterpretation:
  the U.Role filling RoleValueSlot is interpreted through the exact
  taxonomy episteme and effective reference-scheme fillings.

RA-3 AssignmentEpisode:
  the assignment predicate obtains without interruption for the four required
  actual participants; any assignmentInterval states the currently known
  temporal extent in an assertion or occurrence description.
RA-4 NoAssignmentOverread:
  the assignment occurrence alone does not establish capability,
  role state, method admission, performed work, responsibility,
  authorization, evidence sufficiency, or publication currentness.

RA-5 InterpretationQualification:
  any selected model-use structure is designated by the receiving assertion
  or work use, not as a participant of generic U.RoleAssignment.

An evidence gap makes the assignment claim unknown or unrecovered; it does not demonstrate that the assignment predicate failed. A demonstrated non-assignment interval, by contrast, ends the current occurrence.

#Demand-Driven Materialization

Ordinary use can stop at a readable direct assertion:

During Shift-17, Robot-7 holds InspectorRole as interpreted by
MaintenanceRoles-2026 under Maintenance-Scheme-A.

Expose the relation occurrence explicitly only when a receiving claim needs to refer to it, distinguish it from another episode, or use it as a participant. If any required participant filling or the continuity of the assignment episode cannot be recovered, keep the assertion reduced or lower the receiving claim. Do not insert a dummy filling or put a value of another kind into a declared slot.

#Direct Neighboring Relations

A constituting decision, installation relation, or another assignment-establishing occurrence can help make a specialized assignment relation obtain only when that direct ontology says so. Evidence, reliance, and provenance relations instead support knowledge or use of the assignment claim. Do not use epistemic support as the world-side constituting condition by default.

#Performed-Work Attribution

When dated work is performed under role holding, name the admitted holder System, exact Work, and exact assignment directly:

Robot-7 performed InspectionWork-17 under RoleAssignment-17.
performedUnderAssignment(InspectionWork-17, RoleAssignment-17)

Robot-7 is the admitted System in RoleAssignment-17.HolderSystemSlot. [A.15.1](/generated/patterns/A.15.1) governs InspectionWork-17; [A.2.1](/generated/patterns/A.2.1) governs RoleAssignment-17; [F.6](/generated/patterns/F.6) owns the attribution relation. The assignment does not prove that work occurred, and the work occurrence does not alter assignment identity.

If source wording says RoleEnactment, recover the dated U.Work occurrence, exact U.RoleAssignment, admitted holder System, and direct performedUnderAssignment(W, RA) relation. Do not introduce a second run-time U-kind or relation occurrence beside work and assignment.

#Legacy Context Shorthand

Holder#Role:Context@Window is source notation, not the assignment ontology. Context is an untyped source label here. Recover the exact referent, its kind, and the direct relation that makes it relevant. If it denotes an independently selected BoundedModelUseStructure that changes a receiving interpretation, designate that structure in the receiving assertion or work use. Otherwise keep the recovered referent in its own direct relation; never invent a generic context or model-use participant for U.RoleAssignment.

#Archetypal Grounding

#Robot Assigned for One Inspection Shift

RoleAssignmentAssertion:
  participantDesignations:
    HolderSystemSlot: Robot-7
    RoleValueSlot: InspectorRole
    RoleTaxonomyEpistemeSlot: MaintenanceRoles-2026
    EffectiveReferenceSchemeSlot: Maintenance-Scheme-A
  assignmentInterval: [2026-07-13T09:00, 2026-07-13T17:00]

The four SlotKind-labelled fields designate the actual relation participants. The assignmentInterval field states the assertion's temporal description of the occurrence; it is not a fifth relation-participant designation. During the shift, the direct assignment predicate obtains for the four actual participants—Robot-7, InspectorRole, MaintenanceRoles-2026, and Maintenance-Scheme-A; the displayed RoleAssignmentAssertion states those participant designations and describes the occurrence's temporal extent. Sensor capability, current role state, the inspection method, and any performed inspection work remain separate claims.

#Repeated Assignment Episodes

Robot-7 is assigned the same role again on the next day under the same taxonomy and scheme. The four stable participant fillings match, but the assignment predicate does not obtain continuously across the two shifts. The second shift is therefore another U.RoleAssignment occurrence. A staffing table that reuses one row identifier must not collapse the two world-side episodes.

#Motor Holding a Drive Role

RoleAssignmentAssertion:
  participantDesignations:
    HolderSystemSlot: Motor-M1
    RoleValueSlot: DriveMotorRole
    RoleTaxonomyEpistemeSlot: PumpAssemblyRoles-v4
    EffectiveReferenceSchemeSlot: Pump-A-Operating-Scheme
  assignmentInterval: [2026-07-01T08:30, open]

The open end says that this episteme does not yet state the occurrence's end. Extending or later closing that temporal description does not create another assignment while the direct predicate obtains continuously for the same four participants. The holder is the motor as a U.System. Pump Assembly A is the actual system in which installation and work occur; it is not an assignment context slot. Torque capability, electrical interface relations, installation work, and a later pumping run remain direct neighboring claims.

#DDD Model-Use Structure Changes a Receiving Interpretation

Two software teams use ApproverRole under different model vocabularies. In the fulfilment model it admits acceptance of a fulfilment-state transition; in the payment model it admits payment authorization. The generic assignment still has exactly four participants:

RoleAssignmentAssertion:
  participantDesignations:
    HolderSystemSlot: ApprovalService-2
    RoleValueSlot: ApproverRole
    RoleTaxonomyEpistemeSlot: FulfilmentRoles-v3
    EffectiveReferenceSchemeSlot: Fulfilment-Approval-Scheme
  assignmentInterval: [2026-07-13T10:00, 2026-07-13T18:00]

ReceivingInterpretationUse:
  roleAssignmentRef: ApprovalService-2-ApproverAssignment
  selectedModelUseStructureRef: Orders-Fulfilment-ModelUseStructure

The second block belongs to the receiving assertion or work use. It does not add a fifth participant to U.RoleAssignment and does not change generic occurrence identity. The selected structure was independently recovered under [A.1.1](/generated/patterns/A.1.1); it neither assigns the service nor performs approval work. If a future dependent relation species truly obtains only with one selected structure, its direct pattern must declare that structure as a required identity-bearing participant.

#Reviewer and Review Report

ReviewService-4 holds ReviewerRole through ReviewService-4-ReviewerAssignment and, as that assignment's admitted holder System, performs ReviewWork-82 under it through F.6 performedUnderAssignment(ReviewWork-82, ReviewService-4-ReviewerAssignment). ReviewReport-82 is a separately identified U.Episteme; when the work first constitutes that exact episteme and the inception claim matters, A.15.PROD recovers the local work/change/identity claim. Its content may state a review judgment under the direct evaluation pattern. A later evidence relation may use the report for another claim; the report never fills HolderSystemSlot merely because it is useful.

#Bias Annotation

#Working Guidance

1. State the assignment predicate in ordinary language.
2. Name the four required relation participants, then state the currently known temporal extent separately as an AssignmentInterval in the assertion or occurrence description.
3. Decide whether a receiving use needs explicit occurrence identity. Stop at the readable assertion when it does not.
4. Distinguish repeated episodes by temporal extent; do not use a database row identifier as the discriminator.
5. Keep capability, role state, method admission, performed work, responsibility, decision, evidence, reliance, provenance, and publication under their direct patterns.
6. When a selected model-use structure changes a receiving interpretation, designate it in that receiving assertion or use; do not extend the generic assignment signature.
7. For old Context shorthand, recover its exact referent, kind, and direct governing relation before continuing.

#Conformance Checklist

#Common Anti-Patterns

#Consequences

#Rationale

U.RoleAssignment is admitted because a role value and holder identity answer different questions. U.Role is the admitted kind for role values; one exact role value carries the work-facing participation meaning. One obtaining assignment occurrence RA : U.RoleAssignment relates one admitted System to that role value through one role-taxonomy episteme and one effective reference scheme over its maximal continuous extent. A separately identified assignment assertion or description may designate those four participants and state the occurrence's temporal extent. U.Work is the admitted kind for work individuals; one W : U.Work is the world-side dated occurrence. A separate assertion or record may say that W occurred and state its obtaining relations.

The assignment is a relation occurrence, not a relation value stored in a row. Its participant meanings and temporal episode provide the domain identity required by A.6.REL. This prevents two opposite errors: treating every role label as a complete assignment, and requiring explicit assignment-occurrence individuation for casual recognition text.

The role-taxonomy episteme and effective reference scheme provide semantic locality directly. They remove the need for mandatory U.BoundedContext. A selected model-use structure remains available to a receiving assertion or work use without becoming an agent, role taxonomy, generic assignment participant, or identity component.

#SoTA-Echoing

#Relations

Builds on: A.2 for U.Role; A.6.REL for relation obtaining and occurrence identity; A.6.5 for SlotSpec discipline; C.2.1 for the role-taxonomy episteme and effective reference scheme.

Coordinates with: A.2.2 for capability; A.2.5 for role state; A.2.7 for selected role relation structure; A.3.1, A.3.2, and A.15 for method admission; A.15.1 and F.6 for performed-work attribution.

Uses when current: A.1.1 for an optional selected model-use structure; F.9 and A.6.9 for cross-scheme alignment; direct responsibility, decision, evidence, reliance, provenance, currentness, and publication patterns for claims about the assignment occurrence.

Does not replace: role value, role state, capability, method, work, assignment decision, evidence, publication, or their descriptions.

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

#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 occurred, which system exposes access, or which evaluation method and A.10 evidence relations support a fulfilment assertion.

Typical moments:

• an SLA publication, service catalog, product offer, public API promise, utility offer, or government-service description contains a statement about 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 fulfilment claim needs evaluation work that applies declared acceptance criteria to exact delivery-work facts, affected entities and post-work states, and any exact delivery or acceptance relation current for the use; the actual evaluation-operation result binding, optional verdict episteme, and A.10 evidence relations remain separate;

Primary EntityOfConcern. The EntityOfConcern of this pattern is U.PromiseContent: a consumer-facing promise-content episteme. At species level, its C.2.1 EntityOfConcernSlot is filled by the A.7 OutcomeSpec episteme denoted by promisedOutcomeSpecRef. Its claim graph states the promised outcome, any eligibility predicate, and acceptance claims; accessSpec separately describes the access method when that description is current.

First useful move. Write the promise content as a clause: what outcome is promised, which consumer role and claim scope are eligible, how access is described when relevant, and which acceptance criteria selected work facts and post-work states must satisfy. Name the evaluation method, evidence epistemes, and A.10 evidence relations separately so a fulfilment assertion can be checked. 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 with direct exits to commitment, role assignment, access, PromiseContentUse, performed delivery work, affected entities and states, evaluation-operation results, optional verdict epistemes, evidence, acceptance, and publication patterns. Each neighboring claim keeps its named EntityOfConcern and direct relation instead of being collapsed into one undifferentiated service referent.

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 the current move 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. When "service" denotes something else, recover the current referent: a provider or access point as U.System, provider participation as U.RoleAssignment, an access description as U.MethodDescription, performed delivery as U.Work, or the named direct relation governed by its own pattern. Normative prose uses 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 the promise-content episteme and PromiseContentUse. Role assignment, access specification, delivery work, actual operation application and result binding, result-episteme identity, affected-subject change, A.10 evidence relations, evaluation, commitment, delivery, acceptance, speech act, and publication remain with their direct governing patterns. A.6.8 restores which service facet the wording denotes; it does not replace the named participants and their direct relations with a locally minted service-situation relation. A.6.C governs the Contract Bundle lens when contract, SLA, or guarantee wording must be unpacked.

Plain reading. Promise content says what a consumer may rely on. A system holding the provider role through a named U.RoleAssignment occurrence performs delivery work by enacting a U.Method; a U.MethodDescription describes that method. PromiseContentUse obtains between the delivery-work occurrence and the selected promise-content edition during the named interval. Exact work-participation, affected-referent, actual-change, delivery, and acceptance relations state what happened. A separately performed evaluation applies the declared operation or method; its actual result binding states the evaluation value. If another use needs a verdict episteme, C.2.1 governs that episteme and A.15.PROD governs any current entity-identity-inception claim. Evidence relations support the relied-on assertions. No universal work-result relation is presumed.

Lexical note (L-SERV and RPR-SERV). Bare service does not determine one FPF referent. When that word carries a relied-on claim, use A.6.8 to select the service facet: for example, a promise-content episteme and an access-point system have different kinds and participate in different relations. E.10 L-SERV triggers that recovery; after the facet is known, its direct governing pattern applies.

#Problem

Without a first-class U.PromiseContent, a project description tends to make five recurring category errors:

1. Provider = Service. Calling the provider system or team “the service” collapses that provider referent with the promise-content episteme.
2. API = Service. Treating an interface or endpoint as the service hides the promised consumer-side outcome and its acceptance criteria.
3. Method or plan = promise content. Treating a semantic method, a method-description episteme, or a work plan as the promise content hides the consumer-facing outcome and acceptance claims.
4. Run = Service. Logging Work as "a service" erases the promise-content episteme and acceptance specification needed for SLA reasoning.
5. Business ontology lock-in. Large domain schemes are imported wholesale, losing FPF universality and comparability across projects and domains.

#Forces

#Solution - Define U.PromiseContent as the promise-content episteme

Definition (normative). A U.PromiseContent is an externally oriented promise-content episteme. Its claim content states a promised consumer-side outcome, any eligibility predicate, and acceptance criteria by which fulfilment is evaluated. Its optional accessSpec describes the access method. Interpretation is fixed by its effective U.ReferenceScheme; U.ClaimScope states where the claims hold.

U.PromiseContent is not a deontic commitment relation. One or more explicit U.Commitment occurrences under A.2.8 may have the promise content in their referents position; the promise-content episteme does not obligate an actor by itself.

In normative prose, the head phrase is promise content. Service offering clause and service promise clause are admissible Plain twins under A.6.8; bare service does not identify a promise-content episteme.

Species-level identity follows C.2.1:

PromiseContentIdentity = <
  content,
  promisedOutcomeSpecRef,
  effectiveReferenceScheme
>

promisedOutcomeSpecRef is the species-level realization of EntityOfConcernSlot; it is a U.EpistemeRef that resolves to the A.7 OutcomeSpec episteme about which the promise claims are made. OutcomeSpec is a specification-use episteme form, not a separately admitted U-kind. claimScope and optional modelUseStructureRef qualify interpretation and applicability of the promise-content claims; they are not generic identity positions. A direct dependent species may strengthen identity only through its own governing pattern.

• FPF kind: U.Episteme.
• Time stance: the promise content can be authored before delivery; later exact delivery-work facts, affected entities, post-work states, and any current delivery or acceptance relations are tested against the declared outcome and acceptance predicates. Evaluation work and the actual operation-result binding remain separate; when a verdict episteme is constituted, C.2.1 and A.15.PROD govern its identity and inception, while A.10 evidence relations support the relied-on assertions.
• Orientation: consumer-facing promise claims, not provider capability claims.
• Publication boundary: isCarriedBy may obtain between a U.EpistemePublication and a U.PresentationCarrier. Promise-content identity follows the C.2.1 episteme identity rule; neither the isCarriedBy occurrence nor carrier identity enters that rule.

#Promise-content schema

U.PromiseContent : U.Episteme {
  content                  : U.ClaimGraph,
  promisedOutcomeSpecRef   : U.EpistemeRef, resolving to OutcomeSpec,
  effectiveReferenceScheme: U.ReferenceScheme,
  providerRole             : U.Role,
  consumerRole?            : U.Role,
  claimScope?              : U.ClaimScope,
  accessSpec?              : U.MethodDescription,
  acceptanceSpec           : U.Episteme,
  unitOfDelivery?          : U.Episteme,
  modelUseStructureRef?    : U.StructureRef
}

• content carries the promised-outcome, eligibility, and acceptance claims together with the optional accessSpec value when an access-method description is current; it is not an untyped text slot.
• providerRole and consumerRole are U.Role values carried by value in the claim graph. accessSpec, acceptanceSpec, and unitOfDelivery are episteme values carried by value in the claim graph; a publication or other declared representation may express them through U.EpistemeRef values that resolve to those same epistemes without changing their kinds. Changing any of these values changes content and therefore the promise-content identity.
• promisedOutcomeSpecRef resolves to the A.7 OutcomeSpec episteme. It is neither a U.Work occurrence, an affected or delivered entity, an actual operation-result binding, nor a verdict episteme.
• effectiveReferenceScheme makes the claim graph and its references interpretable.
• providerRole and consumerRole are role values; actual providers and consumers enter through named U.RoleAssignment occurrences.
• claimScope states the operating conditions, populations, locales, or other slices over which the promise claims hold.
• accessSpec describes the access method enacted when a holder system under an eligible consumer U.RoleAssignment requests access; an access-point system remains separate.
• acceptanceSpec states the acceptance criteria, identifies the evaluation method through its U.MethodDescription, and states evidence-admissibility conditions for supported assertions; actual evidence relations remain separate.
• unitOfDelivery states how accepted delivery work is counted when counting is current.
• modelUseStructureRef is present only when an independently selected BoundedModelUseStructure changes interpretation for the current PromiseContentUse occurrence.
• An internal delivery method remains U.Method. An already identified episteme is a U.MethodDescription only when its exact EntityOfConcern resolves to that Method and at least one claim says how that Method is done. A promise-content or acceptance claim may cite that episteme for one named use; Method-selection work, performed work, and PromiseContentUse remain separately governed.

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

promisedOutcomeSpecRef points to an A.7 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 post-work state or affected referent 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 -> A.7 OutcomeSpec, referenced via promisedOutcomeSpecRef.

• promiseOutcome -> an extensional delivered outcome instance. It does not have one kernel kind; it is the run-time reality that satisfies the outcome specification, interpreted according to 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 identifies the extensional delivered outcome by citing the relevant U.Work occurrences, exact affected or delivered entities, applicable actual-change and delivery relations, and the selected Delta expression for affected referents together with their pre-work and post-work states on the declared state plane (A.15.1:4.2 item 10). Evidence epistemes derived from telemetry may enter A.10 evidence relations supporting claims about those facts and states and about later evaluation-result epistemes; neither an evidence episteme nor the U.PresentationCarrier filling the carrier position of its isCarriedBy relation is the delivered outcome.

When bundling, invoicing, or dispute handling needs a downstream claim to identify the delivered instance, that claim's episteme separately references the delivery-work occurrences, affected entities, post-work states, evidence epistemes, and A.10 evidence-relation occurrences under their direct governing patterns. It does not create a local OutcomeInstance kind, collapse the delivered reality into OutcomeSpec, or let an invoice, dispute record, other record form, or U.PresentationCarrier become either the episteme or the delivered instance.

A conforming OutcomeSpec uses this explicit-RefKind reading of the specification-use shape in A.7:5.10.2:

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

  workSpec?: {
    methodConstraintRef?: U.EpistemeRef,          // resolves to the U.MethodDescription constraining the promised work
    workPredicateRef: U.EpistemeRef               // resolves to a predicate on selected facts about U.Work occurrences
  },

  resultSpec?: {
    entityOfConcernRef?: U.EntityRef,             // affected referent whose declared FPF kind is named
    statePlaneRef?: StatePlaneRef,                // where the predicate lives (A.7:3 pins)
    postConditionRef: U.EpistemeRef               // resolves to the post-state predicate; evidence supports the resulting claim separately
  }
}

• 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: entityOfConcernRef identifies the affected entity, statePlaneRef identifies the state plane when current, and postConditionRef identifies the required post-work state predicate.
• Counting is not part of OutcomeSpec. Counting lives in U.PromiseContent.unitOfDelivery as the countingRule mini-schema (A.7:5.10.3). Outcome specifications say what counts as delivery; unit-of-delivery specifications 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 work-and-result specification. If a passage means the affected entity, name that entity and link it to resultSpec.entityOfConcernRef. If it means the required post-work state, name the state predicate and link it to resultSpec.postConditionRef. If it means the promised work occurrences, say work as promised and link them to workSpec.

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

Projects may express acceptanceSpec with the following small schema when downstream evaluation work requires replayable criteria and verdict semantics:

AcceptanceSpec (recommended) ::= {
  targetOutcomeSpecRef?: U.EpistemeRef,          // resolves to OutcomeSpec; default is SC.promisedOutcomeSpecRef
  criterionRefs: [U.EpistemeRef],                // each resolves to one evaluation-criterion episteme
  evaluationMethodDescriptionRef: U.EpistemeRef, // resolves to the U.MethodDescription for evaluation work
  verdictScaleDescriptionRef: U.EpistemeRef,     // resolves to one declared scale description
  GammaTimePolicyRef?: U.EpistemeRef             // resolves to the policy selecting the evaluation window
}

• targetOutcomeSpecRef makes explicit which promised outcome is being judged; if omitted, it is the containing promise content’s promisedOutcomeSpecRef.
• criterionRefs resolve to evaluation-criterion epistemes. Their predicates are evaluated over the same selected work facts and post-work state references used for the targeted OutcomeSpec; direct evidence relations separately support assertions about those facts and states.
• evaluationMethodDescriptionRef resolves to the U.MethodDescription for the method enacted by evaluation work. The description does not perform the evaluation.
• verdictScaleDescriptionRef resolves to one scale-description episteme governed by the characteristic and scale patterns. That description states the admitted verdict values and how non-delivery is represented. Informative examples include Boolean pass/fail, trichotomy pass/partial/fail, or named graded values, with non-delivery represented as fail, N/A, or Inconclusive; these values are examples, not defaults.
• GammaTimePolicyRef keeps temporal selection explicit and non-retroactive (F.10 and F.12): it resolves to the policy stating whether judgement is per work occurrence, reporting window, or another named temporal selection. Population and locale remain in U.ClaimScope; they are not temporal-policy values.

This mini-schema is a recommendation only: it does not admit another U-kind. An acceptance-specification episteme may contain these declared schema fields by value or refer to their values through the declared RefKinds. The resulting episteme remains inspectable and bridge-ready without turning its publication form into identity.

#What U.PromiseContent is not

• Not a provider: use a named provider U.RoleAssignment occurrence whose holder is the provider U.System.
• Not a deontic commitment: that is U.Commitment (A.2.8) whose referents include the promise content when that accountable relation is current.
• 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 method description: the semantic way of doing is U.Method; a recipe or other episteme describing that way is U.MethodDescription.
• Not delivery work or its description: performed delivery is U.Work; a ticket, case description, or incident description is a separately governed episteme about planned or performed work.
• Not a schedule: that is U.WorkPlan.
• Not a capability: capability is the provider system's admitted ability to perform a declared work family and meet any declared result-class predicate within its U.WorkScope, measure set, qualification window, and currentness condition. Delivery under a promise may depend on one or more capability instances, but the promise-content episteme is not a capability.
• Not its scope or use interval: U.ClaimScope states where the promise claims hold, U.WorkScope states where a provider capability can deliver work, and PromiseUseIntervalSlot states when one PromiseContentUse occurrence obtains. These are three different values.

#Promise content, delivery work, and evaluation work

• Before delivery work: The promise-content episteme declares its effective U.ReferenceScheme, named U.ClaimScope, promised outcome specification, access specification when current, and acceptance specification. The provider system's ability remains a holder-dependent U.Capability instance under A.2.2. A capability-fit predicate tests that instance against the thresholds selected for the planned delivery work, including any threshold stated by the chosen method description. Method-selection work may yield a C.11 ChoiceResult; enactsMethod obtains between the later delivery-work occurrence and the selected U.Method. A relied-on episteme is a U.MethodDescription only when it meets A.3.2 membership, and the promise-content or acceptance claim may cite it for the named use. That citation establishes neither Method selection, later enactsMethod, PromiseContentUse, evidence, nor acceptance.

• Run‑time: The admitted holder system S = consumerRA.HolderSystemSlot of the named consumer U.RoleAssignment performs request or visit U.Work under that assignment. When the attribution is stated explicitly, use performedUnderAssignment(requestWork, consumerRA). The admitted holder system S = providerRA.HolderSystemSlot of the named provider U.RoleAssignment performs delivery U.Work under that assignment. When the attribution is stated explicitly, use performedUnderAssignment(deliveryWork, providerRA). A system performing evaluation work enacts the evaluation method described by acceptanceSpec; the actual evaluation-operation application carries its exact argument bindings and evaluation-result value. When another use needs a durable verdict episteme, C.2.1 governs that episteme and A.15.PROD governs any current entity-identity-inception claim. The counting rule stated by unitOfDelivery maps admitted fulfilment occurrences to unit counts. The verdict episteme may assert whether a named service-level objective or another acceptance criterion was satisfied during the declared window. When a separately obtaining U.Commitment has the same U.PromiseContent in its referents position, the supported assertion concerns fulfilment of content that is also a referent of the obligation. Neither the operation-result binding, verdict episteme, nor commitment is a property of the promise-content episteme.

  In each performedUnderAssignment(W, RA) occurrence, WorkOccurrenceSlot is filled by W and RoleAssignmentSlot by the named A.2.1 assignment occurrence RA; the admitted holder system S = RA.HolderSystemSlot is the actual performer. The assignment does not act, and no provider-assignment or consumer-assignment pseudo-kind is introduced.

Memory hook: Promise content states what is promised. A method constrains possible work. A system performs work. Evaluation binds a result value. A verdict episteme states the judgment. Evidence supports that assertion.

#Didactic card: Relations around one service-delivery evaluation

Didactic (non-normative). This representation keeps each promise-content episteme, access-description episteme, work occurrence, and direct relation in one delivery evaluation visible without prescribing an order of work. Promise content and an access description remain epistemes; commitment and role assignment remain relations; delivery and evaluation remain work occurrences; evidence remains in its A.10 relations. When order matters, describe semantic method order in U.MethodDescription, intended dated order in U.WorkPlan, and transformation dependencies in the governing TransformationFlowStructure.

U.PromiseContent states the promise. An A.2.8 U.Commitment relation may refer to that content; its accountable-subject position is filled by the accountable subject. In a provider U.RoleAssignment, the holder-system and role-value positions are filled by the provider system and provider role. Delivery U.Work occurs. Evidence relations support claims about selected delivery-work facts and post-work states. A system performing evaluation work enacts the evaluation method; the actual operation application carries its result binding, while any verdict episteme is separately governed by C.2.1 and any current identity-inception claim by A.15.PROD.

This informative diagram is a publication-side representation, not new ontology. It prevents two category errors: treating U.PromiseContent as the addressable access system, and treating a publication-side list or diagram of service senses as a relation occurrence that replaces the direct relations shown here.

flowchart LR
  SC["Promise content<br/>(U.PromiseContent episteme)"]
  C["Commitment<br/>(deontic relation, when current)"]
  RA["Provider role assignment<br/>(A.2.1 relation occurrence)"]
  W["Delivery work<br/>(U.Work occurrence)"]
  EV["Evidence epistemes<br/>(observations used as evidence)"]
  EW["Acceptance evaluation<br/>(U.Work occurrence)"]
  ER["Evaluation result<br/>(U.Episteme with verdict value)"]

  C -->|"refers to"| SC
  %% The accountable-subject position of the commitment is filled directly; no universal commitment-to-assignment relation is asserted.
  W -->|"performedUnderAssignment"| RA
  EW -->|"evaluates selected facts about"| W
  EW -->|"criteria from"| SC
  EW -->|"evaluation operation; result binding stated in ER"| ER
  EV -->|"A.10 evidence relation supports verdict assertion in"| ER

Reading guide (one breath).

• The promise content is the consumer-facing outcome and acceptance statement.
• In the A.2.8 commitment relation, the accountable-subject position is filled directly and the referents position contains the promise-content clause.
• The provider role assignment identifies the holder system, provider role, role-taxonomy episteme, effective reference scheme, and assignment window. The holder system acts under that assignment.
• A.6.8 recovers the selected facet denoted by "service" wording. It adds no service-situation participant: provider assignment, access description, access-point system, delivery system, delivery method, promise content, and work occurrence retain their direct kinds and governing patterns; A.10 separately governs the evidence relations.
• Delivery work is what happened. Evidence relations support claims about selected facts concerning that occurrence and any post-work state expressed by its selected effect Delta. A system performing evaluation work enacts the declared evaluation method over those facts and states; the actual evaluation operation has its own result binding, and a separately constituted evaluation-result episteme may carry the verdict assertion.

Litmus rule (addressability). If the current claim is about invocation, connection, visitation, restart, or scaling, its EntityOfConcern is an actual U.System, not the promised-outcome statement. Use a service access point when the interaction boundary is current and a service delivery system when the realization system is current.

#Archetypal grounding (engineer‑manager friendly)

Key takeaway. The same pattern yields one promise-content episteme in each domain without treating the promise as the provider, access point, method, work occurrence, evidence, operation-result binding, or verdict episteme. Direct role-assignment, PromiseContentUse, evaluation-operation, evidence, acceptance, and publication relations retain their own participants and governors; evaluation remains separately performed U.Work.

#Bias-Annotation

A.2.3 repairs the collapse of several service-related referents into one service label. A visible service name often denotes provider, access point, method, work, commitment, ticket, evidence, and promised outcome without saying which claim is current. The pattern recovers the promise-content episteme first; A.2.8 then governs commitment, A.2.1 provider participation, A.3.2 access description, A.15.1 delivery work, A.10 evidence claims, and the direct outcome and acceptance patterns their respective relations.

In a contract or SLA agreement, an A.2.8 U.Commitment may have promise content in its referents position. A contract document, SLA publication, service catalog, API page, or offer publication may be a U.PresentationCarrier for U.EpistemePublication values describing the agreement, promise content, commitment, or fulfilment work. These relations, epistemes, and carriers retain separate identities.

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

A common service diagram is a representation. Recover the represented systems, epistemes, work occurrences, and relation occurrences as follows:

• Provider participation -> one named U.RoleAssignment occurrence with holder system, provider role value, role-taxonomy episteme, effective reference scheme, and assignment window. The admitted holder system performs each selected delivery-work occurrence under that assignment; when stated as a direct relation, use performedUnderAssignment(deliveryWork, providerRA).
• Acceptance criterion -> an evaluation-criterion episteme in U.PromiseContent.acceptanceSpec; its target values, verdict scale, and GammaTimePolicyRef remain explicit. A U.WorkPlan is added only when planned delivery or evaluation work is current.
• SLA obligation -> an A.2.8 U.Commitment occurrence whose referents position is filled by the relevant U.PromiseContent. Use A.6.C when one SLA publication combines wording about commitment, promise content, evidence specification, and publication relations and must be unpacked through its Contract Bundle lens.
• Published SLA terms -> the U.EpistemePublication for the promise content, together with its isCarriedBy relation to a U.PresentationCarrier. When publication work also communicates or institutes a commitment, add the named A.2.9 speech-act and A.2.8 commitment relation occurrences; publication alone neither creates the commitment nor establishes fulfilment.
• Operating conditions -> the named U.ClaimScope under A.2.6. The acceptance specification may cite that scope; it does not replace it.
• Promised subject -> resolve promisedOutcomeSpecRef, then use the resulting OutcomeSpec.resultSpec.entityOfConcernRef together with the exact affected referent, post-work state, and any direct delivery or acceptance relation current for the claim.
• Customer material—“ours versus theirs.” -> If the current claim depends on who owns or has custody of data, an asset, or a case, name the exact governed role assignment or ownership/custody relation and its actual participants. Do not make ownership or custody a kernel-global property of U.PromiseContent.
• Access -> accessSpec : U.MethodDescription describes the method enacted when an eligible consumer holder system requests access. Actual endpoints, desks, and manifolds remain access-point U.System values.
• One PromiseContentUse occurrence -> consumer request work and provider delivery work remain separate occurrences, each attributed through its own performedUnderAssignment(W, RA) relation to a named assignment whose holder system actually performs the work. When request work follows accessSpec, its A.15.1 methodDescriptionRef resolves to that same U.MethodDescription; following the description does not by itself introduce a second relation occurrence. PromiseContentUse obtains between selected delivery work and the selected promise-content edition during PromiseUseIntervalSlot.
• Consumer-side changed entity or relation -> recover the exact affected-referent and actual-transformation facts, plus any local entity-identity-inception, delivery, acceptance, or receiving-use claim that the current promise evaluation needs. If the changed entity is a holder system and its post-work state calls for a new or revised U.Capability instance, use A.2.2 for that capability instance and its currentness relations.
• Service-enabled consumer-side capability or activity -> If the question is about ability, identify the consumer holder's U.Capability instance and state its A.2.2 qualification and currentness claim. If the question is about activity, identify the consumer-side dated U.Work under A.15.1. If the claim also says that delivery changed the consumer or was used by that Work, state only the exact actual-change or receiving-use relation that currently obtains; otherwise keep the objects separate. Do not create another U-kind or a generic capability-use relation. When a domain claim concerns catalog entries, exposure relations, charging relations, or entitlement relations, govern those entries, participants, and relations directly. Relate them to U.PromiseContent only through named relations; do not treat them as components of U.PromiseContent or replace their direct relations with a locally minted context relation.

#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 a consumer-facing promise-content U.Episteme. One or more U.EpistemePublication values may be related to U.PresentationCarrier values through isCarriedBy without changing the promise-content episteme identity; no presentation carrier is the promise content. U.PromiseContent is not a U.System, U.Method, U.MethodDescription, U.Work, or U.WorkPlan.

CC-A2.3-2 (Semantic locality). Every promise content names its effective U.ReferenceScheme, promisedOutcomeSpecRef, and U.ClaimScope when claim extent matters. Cross-scheme or cross-scope reuse uses the identified F.9 bridge occurrence and A.2.6 scope relations. modelUseStructureRef appears only when an independently selected BoundedModelUseStructure changes interpretation. CC-A2.3-3 (Role values stay distinct from holders and assignments). providerRole and, when present, consumerRole are U.Role values interpreted through a named role-taxonomy episteme and effective reference scheme. Actual provider and consumer systems enter through named U.RoleAssignment occurrences; a role label alone does not identify a performer.

CC-A2.3-4 (Acceptance). acceptanceSpec MUST be present and MUST define how delivered U.Work is judged as pass, fail, or a declared grade against named evaluation criteria and target values. Any SLA deontics are represented through U.Commitment. The promise content MUST declare Claim scope (G) where operating conditions, populations, locales, or another claim extent matter. Every verdict cites an explicit Gamma_time window. If the acceptance criteria mention measurable characteristics such as availability, latency, accuracy, cost, or safety, each characteristic MUST be introduced through C.16 and C.25 with its scale, unit when applicable, U.DHCMethod measurement template, and direct evidence relation. If the reading depends on a particular way of measuring, cite the U.MethodDescription that describes that measurement method. The characteristic is referenced by its exact identifier rather than by an unqualified KPI label.

CC‑A2.3‑5 (Access). When the promised use relies on a request-facing access method, accessSpec MUST identify the A.3.2-admitted U.MethodDescription that describes that method. The endpoint, desk, manifold, or other access point remains a separate U.System. If no access-method description is current because access is ambient, accessSpec may be omitted. In either branch, keep an eligibility predicate in the promise content when eligibility is part of the promise; when eligibility depends on a separately obtaining admission relation, refer to that relation under its direct governing pattern.

CC‑A2.3‑6 (Unit of delivery + counting rule). When fulfilment work is counted, declare unitOfDelivery (for example, one request, kWh, or case). The resulting count may fill a declared quantity position in a separately governed charging relation; that charging relation does not determine the unit-of-delivery specification. 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 belong to the performed U.Work occurrence under A.15.1. An incident-log episteme may describe that occurrence and may separately participate in an evidence relation for a stated claim; neither the log nor its participation in that evidence relation fills a U.PromiseContent slot.

CC-A2.3-8 (Provider capability stays separate). When delivery depends on provider ability, use the A.2.2 U.Capability instance for the provider holder system and the separate capability-fit predicate for the planned delivery work. Do not insert capability into promise-content identity or infer capability or fit from the role name. CC-A2.3-9 (Edition and promise-use interval). A change to content, promisedOutcomeSpecRef, or effectiveReferenceScheme creates a new promise-content episteme edition under the C.2.1 identity rule. Each PromiseContentUse occurrence has one promise-content edition and one delivery-work occurrence as participants and PromiseUseIntervalSlot as its temporal qualifier; an untyped version or timespan entry fills none of those positions.

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, work, and evidence stay distinct). Windows and calendars belong to U.WorkPlan (A.15.2). Performed delivery belongs to U.Work (A.15.1). Evidence epistemes and evidence relations support claims about selected facts concerning that work and any post-work state expressed by its selected effect Delta; they are not slots or parts of the work occurrence.

CC-A2.3-13 (Claim scope, work scope, and promise-use interval). The promise-content episteme names U.ClaimScope when its claims are bounded. A provider capability instance names U.WorkScope. PromiseUseIntervalSlot is the temporal qualifier of each PromiseContentUse occurrence. The ScopeCoverage predicate is satisfied only when the selected context slice is covered under an explicit Gamma_time selector; neither temporal extent nor capability scope replaces claim scope.

CC-A2.3-14 (Scheme and scope bridges). Cross-scheme or cross-scope reuse names the identified F.9 bridge occurrence, direction, loss, and congruence level. A bridge may support a narrower mapped U.ClaimScope; it does not mutate the original promise content or create a universal context. CC-A2.3-15 (OutcomeSpec typing). promisedOutcomeSpecRef MUST be a U.EpistemeRef resolving to an A.7 OutcomeSpec specification-use episteme. It MUST NOT point at a concrete U.Work occurrence, affected or delivered entity, actual operation-result binding, verdict episteme, or downstream effect, and OutcomeSpec MUST NOT be written as an independently admitted U.OutcomeSpec.

CC-A2.3-16 (OutcomeSpec is explicit and mode‑complete). promisedOutcomeSpecRef MUST be present and MUST reference an OutcomeSpec that declares mode in {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 predicates and delivery-work relations). For any delivery U.Work occurrence named by PromiseContentUse, let OS be the A.7 OutcomeSpec resolved from SC.promisedOutcomeSpecRef.

• If OS.workSpec is present, the selected facts about the work occurrence satisfy OS.workSpec.workPredicateRef; when methodConstraintRef is present, the enacted method is compatible with that constraint.
• If OS.resultSpec is present, the exact affected referent and post-work state expressed by the selected effect Delta satisfy OS.resultSpec.postConditionRef on its declared state plane; any production, delivery, acceptance, or receiving-use claim remains separately governed.
• A.10 evidence relations obtain between each relied-on satisfaction assertion and its supporting evidence epistemes. Those evidence epistemes are neither delivery-work occurrences, affected or delivered entities, operation-result bindings, verdict epistemes, nor values of OutcomeSpec.workSpec or OutcomeSpec.resultSpec.

Explicitly individuate PromisedOutcomeDeliveryRelation only when a downstream relation or claim must refer to its occurrence identity and only after these mode-specific conditions are established; otherwise retain the readable deliversPromisedOutcome(W, OS) assertion. CC-A2.3-18 (Acceptance evaluation supports rather than constitutes fulfilment). A holder system performs evaluation work by the evaluation method described in acceptanceSpec over the same selected work facts and post-work states used to test delivery under SC.promisedOutcomeSpecRef. The actual evaluation-operation application carries its exact argument and result bindings. When a durable verdict episteme is needed, C.2.1 governs its identity and A.15.PROD governs any current entity-identity-inception claim. That episteme may assert an admitted fulfilment verdict only when the selected work facts and post-work state satisfy the acceptance criteria. A.10 evidence relations support the relied-on assertions; the operation-result binding, verdict episteme, and evidence relations support knowledge of PromiseContentFulfilmentRelation but do not make it obtain. A multi-grade verdict-scale description states how non-delivery is represented.

CC-A2.3-19 (OutcomeSpec ↔ unitOfDelivery coherence). If unitOfDelivery is present, its counting rule states a selectorRef that selects only work occurrences eligible to satisfy SC.promisedOutcomeSpecRef in the declared mode. When one occurrence can fulfil several promise contents, the rule states either dedupeKeyRef or a reference to a counting-policy episteme under its direct governing pattern. A selector may denote work occurrences filling FulfilmentWorkOccurrenceSlot in obtaining PromiseContentFulfilmentRelation occurrences; it does not count work for which fulfilment has not been established.

CC-A2.3-20 (Unit-of-delivery is computable from work facts). If unitOfDelivery is present, it MUST declare its counting rule over selected facts about fulfilment work, cite the U.DHCMethod used for any measurement reading, name the U.MethodDescription when a particular measurement method constrains that reading, state evidence-admissibility conditions, and refer to the evidence epistemes and A.10 evidence relations used, per A.7:5.10.3. The default "1 unit per fulfilment work occurrence" is permitted only for a pure count of fulfilment occurrences.

#Promise-content use, delivery, evaluation, and evidence

Keep PromiseContentUse, PromisedOutcomeDeliveryRelation, evaluation U.Work, the actual evaluation-operation application and result binding, any verdict episteme, and A.10 evidence relations separate. A direct relation may obtain even when the current episteme about it is unresolved; evidence supports the claim and does not become the relation.

#Core relations

PromiseContentUse : U.Relation. This direct use relation obtains between one delivery-work occurrence and one promise-content edition during one named promise-use interval; it makes no fulfilment claim.

PromiseContentUse : U.Relation
  DeliveryWorkOccurrenceSlot: U.Work, U.EntityRef
  PromiseContentSlot: U.PromiseContent, U.EpistemeRef
  PromiseUseIntervalSlot: temporal interval, byValue

Its occurrence key is <DeliveryWorkOccurrenceSlot, PromiseContentSlot, PromiseUseIntervalSlot>. Obtaining of this relation implies neither successful delivery nor intention, judgement, or claim-making by either participant.

PromisedOutcomeDeliveryRelation : U.Relation. This derived relation obtains between one delivery-work occurrence and the A.7 OutcomeSpec resolved from the PromiseContentUse occurrence in which that work participates, when the conditions below hold.

PromisedOutcomeDeliveryRelation : U.Relation
  DeliveryWorkOccurrenceSlot: U.Work, U.EntityRef
  PromisedOutcomeSpecificationSlot: U.Episteme, U.EpistemeRef constrained to A.7 OutcomeSpec

The relation obtains only when one PromiseContentUse occurrence has the delivery work and a promise-content edition as participants, that edition's promisedOutcomeSpecRef resolves to the same OutcomeSpec, and the specification's mode-specific conditions hold. When workSpec is present, selected work facts satisfy workSpec.workPredicateRef. When resultSpec is present, the exact affected referent and post-work state expressed by the selected effect Delta satisfy resultSpec.postConditionRef; any current production, delivery, or acceptance relation remains separately governed. Its occurrence key is <DeliveryWorkOccurrenceSlot, PromisedOutcomeSpecificationSlot>. The readable predicate is deliversPromisedOutcome(W, OS), where OS denotes that resolved OutcomeSpec. An episteme may assert that this relation obtains, and evidence may support that assertion; neither the assertion nor the evidence makes the work facts or post-work state satisfy the specification.

Acceptance evaluation result. A holder system performs evaluation U.Work by the evaluation method described in acceptanceSpec, using the same selected facts about delivery work and post-work states. The actual evaluation-operation application carries exact argument bindings and the verdict value in its declared result binding. When another use needs a durable evaluation-result episteme, C.2.1 governs that episteme, and A.15.PROD governs any current identity-inception claim linking exact work, actual change, and episteme identity. A.10 evidence relations support the relied-on assertions. The promise content does not perform the evaluation or compute the verdict; the operation-result binding, result episteme, and evidence relations support the assertion rather than making the fulfilment relation obtain.

PromiseContentFulfilmentRelation : U.Relation. This derived relation obtains between one delivery-work occurrence and one promise-content edition when the conditions below hold.

PromiseContentFulfilmentRelation : U.Relation
  FulfilmentWorkOccurrenceSlot: U.Work, U.EntityRef
  FulfilledPromiseContentSlot: U.PromiseContent, U.EpistemeRef

The semantic predicate for this relation is satisfied only when PromiseContentUse obtains for the same work and promise-content participants, PromisedOutcomeDeliveryRelation obtains for that work and the OutcomeSpec resolved from that promise content, and the acceptance predicate declared by acceptanceSpec is satisfied for the exact delivery-work facts, affected or delivered entities, post-work state, and any direct delivery or acceptance relation required by the criterion. PromiseContentFulfilmentRelation obtains for the declared participants when that semantic predicate is satisfied. Its occurrence key is <FulfilmentWorkOccurrenceSlot, FulfilledPromiseContentSlot>. The readable predicate is fulfilsPromiseContent(W, SC). A later evaluation may change the supported assertion about whether the relation obtains; it does not change relation identity. When satisfaction of any required predicate is unresolved, no positive fulfilment assertion is available for reliance.

The explicit RelationSignature declarations are warranted only when unitOfDelivery selectors or fulfilment measures refer to relation-occurrence identity. Ordinary prose may stop at the readable predicates when no later relation refers to that occurrence identity.

Invariant: fulfilsPromiseContent(W, SC) implies PromiseContentUse(W, SC, T), deliversPromisedOutcome(W, resolve(SC.promisedOutcomeSpecRef)), and satisfaction of the acceptance criteria declared in SC.acceptanceSpec; an evaluation-result episteme and A.10 evidence relations support the corresponding assertion without becoming relation participants. Invariant: One work occurrence can fulfil several promise contents only when each promise content's counting rule states dedupeKeyRef or refers to a counting-policy episteme under its direct governing pattern; no silent double counting.

#Promise-content delivery measures

Let W(SC, T) be the set of delivery-work occurrences for which PromiseContentUse obtains with SC during interval T. Let W✓(SC, T) be the subset for which PromiseContentFulfilmentRelation obtains with SC.

• 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: declare the characteristic definition and aggregation separately. The definition may use work duration or request-to-completion delta; the aggregation may use an average or named percentile.
• Availability and uptime claims: select one declared characteristic instead of treating the labels as synonyms. Derive its observed characteristic value from selected work facts and telemetry observations through its C.16 measurement template, Gamma_time policy, and evidence relations; cite a U.MethodDescription when a particular measurement method affects the reading.
• Cost‑to‑serve: sum of Γ_work over W✓ per resource category (A.15.1).

Each resulting U.Measure claim is derived from selected facts about U.Work occurrences through its C.16 measurement template and named A.10 evidence relations; when a particular measurement method matters, its U.MethodDescription is cited. The promise-content episteme is never the bearer of resource or time actuals. Aggregation across time uses the Gamma_time policy referenced by the named C.16 measurement template or acceptance specification; an unqualified KPI label does not select that policy. When a measure needs a B.1.4 temporal-phase aggregation of one carrier, name one ContextTemporalAggregation@Context record and its exact selected policy—for example, union of observed values or their convex hull—together with carrier identity, time window, coverage and non-overlap conditions, and admissible use. If those one-carrier conditions do not hold, return to the direct aggregation owner instead of using this example. Union and convex hull are policy choices, not defaults; Gamma_time does not select either by itself.

#Common misclassification repairs

• A microservice label is being used for the whole service claim. Ground the current referent. The deployed software is normally a delivery-system or access-point U.System; the consumer-facing outcome and acceptance claims remain in U.PromiseContent.
• An API label is being used for the whole service claim. When the referent is the interface specification, use U.MethodDescription; when it is the addressable endpoint, use U.System. Neither referent is the promise-content episteme.
• A process or procedure label is being used for the whole service claim. Recover the semantic way of doing as U.Method, its description as U.MethodDescription, planned work as U.WorkPlan, and performed occurrences as U.Work. Keep the promised outcome and acceptance claims in U.PromiseContent.
• A ticket or case record is being used for the whole service claim. Recover its claim-bearing content as a ticket or case-description U.Episteme; keep the publication form and U.PresentationCarrier separate. Relate that episteme to the named U.WorkPlan or U.Work occurrence it describes.
• Cost or elapsed time is attached to the promise content. Keep resource and time actuals on the performed U.Work occurrence. Derive a measure over work occurrences participating in PromiseContentUse only through its declared characteristic, C.16 measurement template, named A.10 evidence relations, aggregation rule, and Gamma_time policy; cite a U.MethodDescription when a particular measurement method affects the reading.
• Promise content is placed in a product or system breakdown. Keep the promise content as an episteme. The access and delivery systems may have parts and selected structures under A.22 and C.30; the promise-content episteme is not one of those parts.
• A person or organization name is stored as the provider role. State the U.Role value and role-taxonomy scheme in the promise content, then use a named U.RoleAssignment occurrence for the provider holder system and assignment window.

#Existing promise-description repair applications

1. Name the promises. As an informative first pass, list roughly 5–15 consumer-facing promises used by the project; the range is a prompt, not an admission threshold. Represent each as U.PromiseContent with effective reference scheme, promised outcome specification, acceptance specification, and claim scope, plus access specification and unit of delivery when current.
2. Separate provider from promise content. Keep people, organizations, machines, and software delivery systems as admitted U.System values; connect the provider holder through a named A.2.1 role-assignment occurrence.
3. Relate promise content to delivery and evidence. Add PromiseContentUse for every delivery-work occurrence evaluated under the promise. Establish PromisedOutcomeDeliveryRelation only after exact work facts, affected or delivered entities, post-work states, and any direct delivery relation required by the resolved OutcomeSpec satisfy it; establish PromiseContentFulfilmentRelation only after those facts and states satisfy the declared acceptance criteria. Record the actual evaluation-operation result binding, any evaluation-result episteme, the evidence epistemes it cites, and the A.10 evidence relations separately.
4. Define evaluation characteristics. As an informative first pass, select roughly 2–4 characteristics for each promise content; the range is a prompt, not a conformance limit. Use a recognizable §8.2 formula family—availability over a named window, lead time as a declared delta plus aggregation, rejection rate 1 − |W✓| / |W|, or cost-to-serve as summed Work resource use—or state an exact declared alternative. For each characteristic, name its scale, unit when applicable, C.16 measurement template, Gamma_time policy, direct evidence relations, and exact formula; cite a U.MethodDescription when a particular measurement method affects the reading. Do not let a KPI label stand in for this declaration.
5. Bridge domain schemes. If a domain ontology already distinguishes business, technical, or internal service kinds and relations, retain its own reference scheme and name the F.9 bridge occurrence used for each selected domain referent and its FPF counterpart.
6. Tidy language. Apply A.6.8 (RPR-SERV) and L-SERV. When "service" denotes a provider or access-point U.System, an access U.MethodDescription, planned U.WorkPlan, performed U.Work, or a ticket or case-description episteme, use that full kind name and reserve U.PromiseContent for the consumer-facing promise content.

#Consequences

#Rationale

Everyday "service" language is useful because one label can denote promise content, provider systems, access points, commitments, methods, work occurrences, and evidence epistemes. When those claims guide evaluation or work, FPF distinguishes the referents and states their direct relations. U.PromiseContent gives the promised-outcome side one stable episteme, A.6.8 recovers the referent intended by the service wording, and each named direct relation remains governed by its direct pattern.

The pattern keeps promise content in the episteme family because it is a clause or description whose outcome and acceptance predicates state conditions on delivery work, affected referents, and post-work states. A fulfilment assertion and the evidence relations supporting it remain distinct from those referents and from the world-side relations whose obtaining the assertion describes. The episteme never becomes an obligation: the referents position of an A.2.8 commitment relation may contain it, an A.2.9 speech-act occurrence may communicate or institute that commitment, and A.6.C may unpack contract or SLA wording carried by a publication, while gate and policy relations remain separate.

#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 distinguishes promised content from obligation-bearing acts or agreements and from later performance evidence. FPF keeps that separation without importing a domain-specific service taxonomy; the promise-content episteme remains usable across IT, utilities, healthcare, public services, manufacturing support, and other project domains.

#Relations

• Builds on: C.2.1 U.Episteme identity and reference scheme; A.2 U.Role; A.2.1 U.RoleAssignment; A.2.2 U.Capability; and A.2.6 U.ClaimScope and U.WorkScope. A.1.1 is used only when an independently selected BoundedModelUseStructure changes interpretation.
• Coordinates with: A.3.1 U.Method; A.3.2 U.MethodDescription; A.15.1 U.Work; A.6.1 for actual operation application and result binding; A.15.PROD for current entity-identity-inception claims; A.15.2 U.WorkPlan; direct affected-subject, delivery, acceptance, and evaluation patterns; A.10 for evidence relations; A.2.8 for commitment; A.2.9 for speech act; A.6.8 for service-wording restoration; F.9 for cross-scheme or cross-scope bridges; and A.7 plus the direct publication pattern when specification use or publication is current.
• Constrained by lexical rules: E.10 L‑SERV (service disambiguation); also L‑FUNC, L‑PROC, L‑SCHED, L‑ACT.
• Informs: reporting and assurance patterns for measures over work occurrences participating in PromiseContentUse, plus directly governed catalog entries, exposure relations, charging relations, and entitlement relations when those claims are current.

#Didactic quick distinctions

• Promise content. A consumer-facing episteme stating the promised outcome, any eligibility predicate, effective reference scheme, claim scope, and acceptance specification; its optional accessSpec describes the access method.
• Method and method description. U.Method is the semantic way of doing. U.MethodDescription is an episteme describing that method; neither is delivery work.
• Delivery work, affected subject, and effect Delta. A provider holder system performs U.Work. Exact affected-referent, actual-change, production, delivery, or acceptance claims state what happened under their own governors; the selected effect Delta is a mathematical-lens expression over the affected referent and its pre-work and post-work states.
• Evidence and evaluation. Evidence relations support delivery and satisfaction claims. A separately performed evaluation occurrence has an actual operation application with a declared result binding; any verdict episteme is separately constituted and governed.
• Provider and consumer participation. U.Role values denote participation positions; the role-taxonomy episteme describes their meanings, and the holder-system and assignment-window positions of named U.RoleAssignment occurrences are filled explicitly.
• Measures. U.Measure claims such as availability or lead-time readings derive from selected work facts through named characteristics, C.16 measurement templates, A.10 evidence relations, aggregation rules, and temporal policies; when a particular measurement method matters, its U.MethodDescription is cited.
• Structure boundary. Promise content is not a structural part. The systems that expose access or perform delivery retain their own parts, selected structures, and ArchitectureOf@Context relations.

#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