#Part A - Kernel Architecture Cluster

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

#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. The kind is already admitted in the current FPF; E.24.UK governs the separate one-time decision to admit public U-kinds. The A.1 candidate test does not repeat that ontology decision.

When the next decision depends on which exact System acts, is intended to change, carries a capability, persists, or is being considered or designated as the project system-of-interest, use A.1.SCR to find that proposed subject. A.1.SCR first checks whether a non-system subject already answers the decision; apply the complete A.1 criterion only while the decision still depends on systemhood.

Once the exact proposed or observed focus is current, use A.1.CSD when the next question is which other Systems may undergo relevant changes and omitting one could change a named decision or investigation. That branch discovers candidate bearers and qualified consequence claims; it does not repeat recognition of the focus or settle causality, evaluation, or choice.

After recognition, use A.1.STM only when the remaining problem is loss of the long dependency from project use through architecture, Work, change, and recursive builders. Otherwise apply the rule that defines or tests the next claim.

What goes wrong if missed. A document edits itself, a theory gets ports, a list becomes an organization, a lathe that changes a workpiece is treated as its containing whole without an obtaining part-whole relation, 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 subject 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, system-role kind or assignment, work, capability, or functioning, use the subject 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, system-role assignments, capability, method, or work evidence.
4. Transformation becomes containment. A system that changes another holon is treated as the larger whole containing it, or as standing in a part-whole relation to it, merely from that 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 system-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 the exact admission predicate defined in the subject pattern is satisfied

This is not a classical taxonomic ladder and not a publication hierarchy. [E.24.UK](/generated/patterns/E.24.UK) is the pattern for public U-kind admission; A.1 is the pattern for 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—for example, a number, claim, named product, material batch, data value, legal clause, local system-role kind, 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. Use E.24.UK for the one-time FPF decision that admits U.Holon and every other public holon kind. A.1 is the pattern for 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.

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.

A person or system performing the receiving work separately decides whether to rely, decline to rely, defer, or reopen. Exact evidence and assurance relations support or warrant assertion claim content. Use G.11 to test whether the selected assertion edition is current. B.2 addresses 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 exact entity being evaluated, six constructive components, admitted kind, kind-specific condition, and resulting judgment needed by the task. Materialize a classification assertion only when a specific downstream task must inspect or cite that judgment. If a system-thinking long map consumes the result, pass only this recognition result and apply A.1.STM; do not add external value, project designation, architecture, Work, or network selection to the A.1 criterion.

Historical read path. Older FPF writing may use super-holon. Under F.13, read it either as the larger system of which S is an admitted part under one exact part-whole relation, or as the rejected inference that interaction, change, control, teaching, measurement, or repair alone makes such containment obtain. Current FPF does not use that historical expression as a head. Environment means the exact external referents and crossing relations made relevant by a stated system delimitation and use; a medium is named as such only when that exact medium is the subject. Neither denotes a generic Context or identifies a containing whole. An actual containing-system claim names the larger system and the exact obtaining part-whole relation.

#Admitted Holon Kinds

Current accepted holon-kind examples are:

• U.System, used here for an acting physical or operational holon;
• U.Episteme, used here only for a non-agentive claim-bearing holon, identified under C.2.1 by exact claim content, EntityOfConcern, and effective ReferenceScheme, with constitution, empirical grounding, and edition kept as distinct direct relations;
• U.Work, admitted under A.15.1 for a dated 4D occurrence holon;
• U.Discipline, defined in C.20 as a field-level practice-and-knowledge holon;
• U.Method, defined in A.3.1, with method-composition patterns such as B.1.5 defining how submethods compose into a whole method across levels.

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 subject pattern. Neither route may rely on part-whole, architecture, system-role-kind classification or assignment, 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.Method and a local system-role kind are not decided by whether they act. U.Episteme already shows that a non-agentive object can be a holon. U.Method is a non-agentive holon kind: submethods can compose into whole methods with whole-level preconditions, effects, invariants, interfaces, constraints, and assurance hooks, and a whole method can participate in a larger method. A step label or step description is not a method part by label: first recover a U.Method submethod rather than a method-description node, order relation, work-plan item, or work occurrence. A local system-role kind is instead an exact local U.Kind whose candidates are U.System values; it is neither a public root U-kind nor a holon kind by kind identity. C.3 recovers it through the candidate domain, operative condition for a stable, assignable, work-facing contribution, intended member/non-member boundary, and continuity rule. A practice or source reference only locates or prompts comparison of the definition; the current KindSignature states the candidate-side condition against direct features of the system. Assignment may be one criterion only when that signature says so; assignment alone does not confer family-wide membership. The assignment occurrence, assignment state, capability, responsibility, permission, commitment, obligation, method participation, and SystemRoleKindRelationStructure remain neighboring objects or relations rather than parts of the kind.

#U.System

U.System is an acting physical or operational holon kind. It can participate in system-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 U.SystemRoleAssignment, work occurrence, or capability relation does not create the system by participation alone.

Keep those relations separate:

• Use A.2.1 to state the U.SystemRoleAssignment 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 defines or constrains 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. Acting systems can use, cite, publish, represent, structure, compare, interpret, or rely on it through separately governed relations. Work may yield another edition, but changed claim content identifies another episteme under C.2.1 rather than an in-place transformation of the same one.

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 may decide, approve, perform work, promise, revise, authorize, or bear responsibility through separately governed relations and Work. Classification by a local system-role kind or an assignment to it supplies none of those acts, permissions, commitments, or responsibilities by itself.

#Recover Holon Delimitation And Boundary Crossing

When a claim concerns where a holon is delimited, recover the delimitation relation, criterion, or selected structure supplied by the direct holon, mereology, architecture, or domain pattern. Do not force an identity rule, collection-belonging 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. State the delimited holon, the direct crossing relation, direction, fit, loss, scope, and qualification window that are current for that use. When the claim also needs a semantic correspondence or difference between two exact F.17 local senses from different semantic contexts, use F.9 for that Bridge question. 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 rules; process-holon wording uses work, method, work-plan, or transformation rules; portal or traversal wording uses an access, crossing, policy, or evidence relation. An exact candidate-side holon or system claim passes only when the A.1 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 rule that defines or tests that recovered claim. The exact candidate is a holon under A.1 only when its constructive criterion is satisfied; the neighboring delimitation claim does not establish 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: who or what belongs to which collection under the collection's own rule and A.14; a possible holon under the complete six-part A.1 test; a C.13 set account of already established belonging; optional B.3.5 assurance; a whole-level characteristic under C.16; an acting collective 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, system-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 subject patterns.

#Constructional Grounding

A.1 governs constructive holon recognition. Exact part-relation patterns govern part relations; C.13 governs constructional grounding; E.24.UK governs public-kind admission.

Use A.14 and the direct relation patterns to identify collection belonging and any independently obtaining component, portion, aspect, phase, constituent, or other constructive part relation. Use C.13 to report how already grounded facts form a collection, assemble the candidate, or distinguish an aspect. If a C.13 trace is materialized, it is a C.2.1 episteme about that construction. Use B.3.5 only when a named assurance use elects its profile.

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, system-role-kind or assignment 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 pattern 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 U.SystemRoleAssignment 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 thereby becoming a part of the changed holon or the larger whole containing it. 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 subject 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;
• U.System is already an admitted public U-kind in FPF; E.24.UK governs admission of public U-kinds, while the A.1 common holon criterion and its U.System clause supply 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 U.SystemRoleAssignment, has a flow-rate capability envelope, and participates in the water-moving transformation. A separate inspection account may identify WO-1842 : U.Work, but the cooling-water assignment does not make Pump #37 its performer: the exact inspector System must have its own A.13 core, the Work must be independently admitted under A.15.1, and F.6 is added only if that account needs precise assignment-bound attribution through the inspector's same obtaining assignment. Pump #37 remains the inspected or participating subject unless another direct performer basis establishes otherwise. 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 identity rule distinguishes this theory episteme; different claim content identifies another episteme, and any historical continuity is stated through the applicable C.2.1 edition relation;
• 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;
• U.Episteme is already an admitted public U-kind in FPF; E.24.UK governs admission of public U-kinds, 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.

A system under an exact U.SystemRoleAssignment may explain, publish, compare, or use this episteme through separately governed Work and relation occurrences; the assignment alone establishes none of those acts. Revision Work yields another episteme, with any edition relation tested separately.

#Fleet As Collection Or Acting Collective

A fleet register supports the claim that a vehicle belongs to the fleet only under its registration rule. In the register-only case the fleet is not a holon: no vehicle-to-whole assembly or composition-grounded characteristic is claimed. Fleet availability is a separate collection characteristic. A fleet-coordination organization that coordinates vehicles, drivers, rules, and Work can be an acting collective U.System only after all six A.1 matters, including its constructive relations and assembly, have been 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 thereby becoming a part of the workpiece or the larger whole containing it.

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.

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 described, compared, published, and relied on; revision Work yields another episteme when claim content changes.
• 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 subject pattern on which it relies.
• Some familiar sentences need repair: "the document decided" becomes a claim about a U.System, the direct decision relation or Work, and an episteme or publication. Add a local system-role kind or assignment only when that separate fact matters.

#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 subject 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 define or constrain 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.1.STM only after recognition when the current problem is use of the system-thinking long attention map; 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.
• Applied by: Use A.1.SCR when a practitioner must find the exact acting or changed System for a decision that depends on systemhood. After an exact proposed or observed focus is current, use A.1.CSD when the next question is which other Systems may undergo relevant changes. Use A.1.STM only when the practitioner still cannot connect a recognized project System to the long dependency map. For a direct Work, Method, capability, structure, episteme, or relation question, apply the pattern that defines or tests that claim instead of invoking this complete criterion.
• 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 actual performer through A.13 and let A.15.1 independently admit the performed Work; because ModelUseRelation expressly represents assignment-bound use, then establish F.6 through the same obtaining A.13 assignment and recover ModelUseRelation, then 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. A.13 first recovers Operator-12 : U.System as the exact actual performer through obtaining OperatorAssignment-8, and A.15.1 independently admits PressOperationWork-91 : U.Work. Because this actual-use claim expressly represents assignment-bound use, exact F.6 performedUnderAssignment(PressOperationWork-91, OperatorAssignment-8) then obtains. The already recovered performer 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; PlantReleaseRule-3 supplies the review obligation; release authority, if needed, is established separately.

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. 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. 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 condition for stopping or returning to its direct relations. If either is missing, stop at the direct relation or the pattern that defines or tests it. Use F.19:4's plausible-reader test for any optional explanatory guard.

Names for retrieval. The Plain label is bounded context and the Tech label is BoundedModelUseStructure. Use F.18 for designation settlement and lineage, and F.17 for the public terminology row and its refresh evidence; A.1.1 keeps only the names needed to apply this pattern. Authors MUST NOT publish U.BoundedContext as a U-kind.

#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 pattern 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 stated through its exact value and relation assertion, with the subject pattern kept only as a locator.

Not this pattern when. If only a term sense, local system-role-kind value, system-role-assignment occurrence, relation among system-role kinds, 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
    stop or return condition
  optional nearest non-admissible overread: explanatory only, subject to F.19:4's plausible-reader test

A selection-use frame is the exact plain value formed by the question, admissible action, and stop or return condition; 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 one of those three values changes that identity discriminator. An optional nearest non-admissible overread may explain the use when it passes F.19:4's plausible-reader test; that explanation is outside the frame's identity.

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.

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.

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. The same use must have an exact A.10 evidence-provenance relation. Ordinary reliance requires RelianceDisposition=pass. If an actual named assurance claim about that use is current, require its B.3 AssuranceResult for the same bounded use: only supported-for-use supports the attempted assurance use, while narrowed supports only its stated narrower use. A direct domain rule may require such a claim.

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

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. The same use must have an exact A.10 evidence-provenance relation. Ordinary reliance requires RelianceDisposition=pass. If an actual named assurance claim about that use is current, require its B.3 AssuranceResult for the same bounded use: only supported-for-use supports the attempted assurance use, while narrowed supports only its stated narrower use. Establish any required authorization separately.

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: recover each exact actual performer through A.13 and let A.15.1 independently admit the occurrence. Add F.6 through the same obtaining A.13 assignment only when the maintenance account or its receiving use expressly consumes precise assignment-bound attribution; F.6 identifies neither assignment nor performer, and missing or failed attribution leaves the Work intact. 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 exact evaluator may separately be recovered through A.13 and perform independently admitted evaluation Work, with F.6 added only for a consumed precise attribution. 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 subject 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. 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, and stop or return condition. An optional explanatory guard follows F.19:4 and remains outside those four discriminators.

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 question/action/stop-or-return 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, or return condition reopens structure identity even when every substrate and relation occurrence remains unchanged. A changed explanatory guard alone reopens the affected use claim, not structure identity. If its changed content alters an applied constraint, question, action, or stop or return condition, compare that existing discriminator. 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. A.10 handles ordinary reliance; B.3 adds a bounded result only when an actual named assurance claim is current. The Bridge is not the rule, unit, status use, inference, or receiving action.

If a subject pattern 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 unresolved interface in the subject pattern. The transfer is not complete merely because A.1.1 names a destination.

#Heterogeneous semantic-locality replays

Hospital operating-room replay. Recover direct values and relations.

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 designates the participant. 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 subject pattern. 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. 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, system-role-assignment occurrence, or direct relation occurrence under its subject 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. Any claim of authority over the Work in the filled cases below needs its own governing basis.

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. A.13 first recovers Operator-12 : U.System as exact actual performer through obtaining OperatorAssignment-8, and A.15.1 independently admits PressOperationWork-91 : U.Work. Because this decision expressly represents assignment-bound model use, exact F.6 performedUnderAssignment(PressOperationWork-91, OperatorAssignment-8) then obtains. The already recovered performer actually uses PressControlModel-5 concerning Press-3 during that 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 ControllerEngineerAssignment-7. First recover Engineer-4's A.13 core for this action, including the same obtaining assignment; A.15.1 then independently admits the dated Work from its performance history, enacted ControllerAlignmentMethod-2, extent, and containing-System relation. Because this case explicitly attributes performance under ControllerEngineerAssignment-7, F.6 afterward relates that already admitted Work to the assignment. The assignment obtains, names Engineer-4 as holder, and covers the Work.
   • 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 CoherenceEvaluatorAssignment-5. First recover Evaluator-2's A.13 core for this action, including the same obtaining assignment; A.15.1 then independently admits the dated Work from its performance history, enacted CoherenceEvaluationMethod-4, extent, and containing-System relation. Because this case explicitly attributes performance under CoherenceEvaluatorAssignment-5, F.6 afterward relates that already admitted Work to the assignment. The assignment obtains, names Evaluator-2 as holder, and covers the Work. State any needed operation application through its 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. F.9 governs correspondence between local senses. Omit the proposed crossing 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; return to the three direct relations if PlantReleaseRule-3 is absent or does not require their joint review. 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. 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. The published NAICS model is 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; without the complete basis, stop at publication availability or the direct relation that actually obtains. The bare scope or one membership result is not an applied constraint.

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. 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. Reidentify each structure using all four discriminators and the continuity rule in section 4.3.

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. Architect-9 : U.System performs dated ContextMappingWork-14 : U.Work under ArchitectureAssignment-6. First recover Architect-9's A.13 core for this action, including the same obtaining assignment; A.15.1 then independently admits the Work from its performance history, enacted ContextMappingMethod-3 : U.Method, extent, and containing-System relation. Because this case explicitly attributes performance under ArchitectureAssignment-6, F.6 afterward relates that already admitted Work to the assignment. The assignment obtains, names Architect-9 as holder, and covers the Work. The repeatable Method and this dated 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 performs ContextViewConformanceEvaluationWork-15 : U.Work under ContextViewReviewerAssignment-10. First recover Reviewer-6's A.13 core for this action, including the same obtaining assignment; A.15.1 then independently admits the Work from its performance history, enacted ContextViewConformanceEvaluationMethod-5, extent, and containing-System relation. Because this case explicitly attributes performance under ContextViewReviewerAssignment-10, F.6 afterward relates that already admitted Work to the assignment. The assignment obtains, names Reviewer-6 as holder, and covers the Work. Any result episteme and any A.15.PROD inception claim about that result remain separate. Under E.17.0, ContextRelationsAnalysis-8 becomes a U.View only when its declared conformance relation to ContextMappingViewpoint-4 obtains.
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 system-role-assignment occurrences 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/stop-or-return 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; its identity uses the four A.22 discriminators and their continuity rule.
5. Reidentification compares all four discriminators and then applies A.1.1:4.3. A changed applied constraint or changed question/action/stop-or-return frame reopens identity even when constituents and relation occurrences are unchanged; a changed optional explanatory guard alone reopens the use it protects; if it changes an applied constraint or frame value, compare that discriminator; 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 subject pattern; 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. When a description claim needs empirical grounding, recover one exact obtaining EpistemeEmpiricalGroundingRelation.
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 subject patterns. 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. Use the structure only when its joint organization changes a receiving decision. The reader can name the admissible action and the stop or return condition; use F.19:4's plausible-reader test for any optional explanatory guard.

#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 subject patterns rather than a context proxy.

Costs. A load-bearing structure claim must recover three direct relation families, exact applied constraints, and one question/action/stop-or-return frame. Semantic transfer sometimes stops at a subject pattern that still cannot express the claim without a generic context field; that stop preserves the known participants and relations while the missing predicate is repaired.

Limits. A.1.1 does not decide model truth, local system-role-kind classification, system-role-assignment occurrence or state, a relation among system-role kinds, 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 includes an independently obtaining crossing only as a selected relation occurrence in 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 define or constrain candidate identity; E.24.UK governs public-kind admission; A.14 and direct part-relation patterns define or constrain parthood; C.13 governs constructive assembly.
• 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 distinguishes local system-role kinds and their classifications. A.2.1 defines and tests U.SystemRoleAssignment species, occurrences, and states; A.2.7 defines and tests any separately needed relation among system-role kinds in model-use loci. E.10.ROLE routes any other technical use of role before one of these claims is selected.
• 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 defines 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 handles ordinary reliance; B.3 adds a bounded result only when an actual named assurance claim is current.
• 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.
• F.19 tests whether an explanatory guard is justified for the intended reader.

#A.1.1:End

#Finding the Acting or Changed System

Type: Part A practitioner application pattern Status: Stable Normativity: Normative unless marked informative

Plain name. Find the system that acts or is intended to change.

Mint or reuse. This pattern introduces no U-kind, relation kind, result kind, or application-record kind. A.1.SCR is a PatternID. It tests one exact U.Entity under the already admitted U.System kind only when a current engineering decision depends on systemhood.

#Practitioner entry

Use this when. Use this pattern when a decision depends on which exact system acts, is intended to change, carries a capability, persists through a lifecycle, or is being considered or designated as the project system-of-interest—and the proposed subject is still unclear. Ask: Which exact system acts or is intended to change here, and what decision depends on treating it as a system?

First useful move. State the claim, the proposed actor or change bearer, and what you will decide differently if it is or is not a system. If the phrase already names Work, a Method, capability, transformation, episteme, structure, or a direct relation and your decision does not depend on systemhood, name that object and leave through its subject pattern. Apply the complete A.1 criterion only in the system-dependent branch.

First-minute recognized case. A maintenance decision asks whether Pump-37 or the larger pumping assembly must be isolated before repair. The exact pump has identified constituents, obtaining part relations and assembly, a reidentification rule across seal replacement, a composition-grounded pumping characteristic, and governed boundary/interface facts. Its organization can causally participate in pumping and maintenance Work while preserving identity. The first result is: Pump-37 is the acting U.System whose boundary controls this isolation decision.

Subject-pattern and proposed-system readings. “We develop the surgeon's mastery” ordinarily names the person, one holder-dependent U.Capability, training Work, or evaluation. Keep those subject-pattern readings. If the source instead proposes the physically or operationally realized whole SutureControl-M17, identify that exact U.Entity and evaluate it—not a substituted surgeon or capability—under the already admitted U.System kind. Choose the reading on which the current decision depends.

Near-identical non-system case. PumpKit-37 contains parts of the same types and carries the same product label, but its constituents are not assembled by the required part relations, it has no composition-grounded pumping characteristic, and it cannot participate in the plant installation while preserving pump identity. The first result is: the kit is not the pump system; the current subjects are the material collection and its description.

Honest unknown case. WorkshopController-9 is an exact boxed device, but the team cannot recover its internal assembly, reidentification rule, or operating boundary. The evaluation is unknown and names those missing inputs; the decision that assumes an acting controller remains blocked. The entity itself satisfies or fails the criterion independently of current knowledge.

What this buys. A real actor, change bearer, lifecycle subject, capability holder, or project system-of-interest decision gets a tested identity and boundary. A direct Work, Method, capability, structure, episteme, or relation question leaves immediately without an unnecessary A.1 evaluation. Continue through A.1.STM only if the practitioner still cannot connect this recognition result to the project's outside use; recognition alone does not open the long map.

Not this pattern when. If the subject and its admitted kind are already clear, use the subject pattern of the claim. If service or access wording hides a promise, participant, bearer, permission, Work occurrence, status, evidence, or direct relation, begin with A.6.P §4.11a. Enter A.1.SCR from that route only when the repaired claim itself depends on whether the exact entity recovered by A.6.P—an exact bearer or access-providing arrangement—is a system. If only a name for an already recoverable object is unclear, use F.18.

#Problem frame

Familiar nouns can pull attention toward the wrong system or erase a supported proposed-system reading. Mastery may name a capability or the exact physical/operational whole SutureControl-M17. Session may name Work, an interval, a record, or GameSessionWhole-GS204. Access may name promise, permission, state, bearer, Work, or InternetAccessArrangement-CA17. Program may mean code, a Method, an intended designator, a deployed realization, or a run. The engineering cost is a wrong actor, identity boundary, change bearer, capability holder, or project system-of-interest—and the same error occurs when a convenient neighboring referent replaces the exact entity before A.1 evaluates it.

A.1 is the pattern for constructive recognition under admitted holon kinds. This child does not relax or duplicate that criterion. It tells the practitioner when the complete test is worth doing, permits an immediate subject-pattern exit when it is not, and returns one result tied to a concrete decision.

#Problem

Without this conditional route, practitioners commonly:

1. classify every unusual noun before asking what the decision needs;
2. treat wording, physical embodiment, a system-role label or assignment, or a record as proof of systemhood;
3. stop at a list of PatternIDs without naming the actor or change bearer;
4. infer designation as the project system-of-interest from recognition or from being affected by Work;
5. reject a system reading without naming the actual Work, Method, capability, structure, episteme, or relation that remains useful.

#Forces

#Solution

#State the system-dependent decision

Start with four plain statements:

1. the claim you are trying to use;
2. the exact entity proposed as actor, change bearer, capability holder, persistent subject, or project system-of-interest;
3. the decision or action that would differ if this entity were or were not a system; and
4. the observation, boundary fact, or construction fact that would settle that difference.

Do not use bare system candidate as a working noun. Before referent recovery say the proposed system reading of the phrase. Once an actual referent is identified, say the exact U.Entity being evaluated under the already admitted U.System kind. Say an alternative being considered for designation as the project system-of-interest only when one named project plan or decision compares possible referents.

#Take the subject-pattern exit first

Before testing systemhood, ask whether the current decision already concerns one of these objects:

If this result answers the decision, stop here. Name the object, its subject pattern, and what you can now do. Do not apply A.1 as a recurring project ritual.

If a needed relation has no current governor, state the exact participants and blocked receiving use, return missing-governor[...], and continue under A.6.RCD. Do not substitute relatedTo, a graph edge, or a local bundle.

#Apply A.1 only when systemhood remains load-bearing

When the decision still depends on systemhood, recover all six A.1 constructive components. A.1 supplies the criterion.

Then apply the already admitted U.System condition: the whole has an actual physical or operational organization through which it can causally participate in Work or transformation while preserving identity. A system-role assignment, capability, Work occurrence, plan, codebase, or description may provide evidence for these conditions.

#Return one decision-bearing result

After one candidate bearer is recognized, rejected, or left unresolved, use A.1.CSD only when the current question is which other Systems may undergo relevant changes and that discovery can change a named decision or investigation. A.1.SCR does not generate the bearer set or qualify consequence paths; it supplies only the load-bearing recognition result or blocker.

These are response forms, not a schema. Persist a classification assertion or evaluation-result episteme only when another use must inspect or cite it; C.2.1 is then the pattern for that episteme. true | false | unknown describes an evaluation and changes no kind extent.

#Add only the neighbors used now

After the first result, add only claims consumed by the decision. Shared extent, one carrier, a common label, or co-occurrence establishes none of their identities or relations.

#Keep service/access recovery independent

When service or access wording is the unresolved phrase, start in A.6.P §4.11a. A.6.P names the exact service-provision Work, Method, PromiseContent, system-role assignment, bearer, access-providing arrangement, permission, status, or direct relation. Use A.1.SCR only if the repaired sentence makes a separate system-dependent assertion about the exact entity recovered there—an exact bearer or access-providing arrangement.

“My service stopped” does not by itself say that a system stopped. Service-provision Work may have ceased, an exact deployed or physical bearer may have stopped or become unavailable, an access-providing arrangement may be proposed as the exact system whose functioning stopped, or promised availability/fulfilment may have failed. Use A.1.SCR only to test a separately proposed exact bearer or access-providing arrangement when its system boundary matters to the decision.

#Preserve the project system-of-interest bridge

The primary expression is project system-of-interest, inherited from systems engineering without adding target, aim, or goal semantics. systemOfConcern may serve as a historical systems-engineering Plain synonym for that same designation.

A project plan or decision may designate one system as the project system-of-interest. Keep six questions separate:

1. identify the exact actual system, or keep a merely intended future referent as a designator in plan, decision, or description content;
2. name the plan or decision that designates it and the intended change or use;
3. admit composite project Work only after A.15.1 and A.15.6 qualifications hold;
4. state each actual work-to-referent, transformation, production, evaluation, delivery, acceptance, or later-use fact under its own governor;
5. test any SystemOfInterestSystemRole interpretation and any A.2.1 system-role assignment separately; and
6. when the recognized system must be reconnected to the long dependency from outside use through architecture, Work, change, and recursive builders, identify each exact admitted performing System, recover its A.13 core, and identify the applicable Method described in A.1.STM before independently admitting each dated Work occurrence under A.15.1. Add F.6 only when the receiving claim also needs precise assignment-bound attribution through that performer's same obtaining assignment. Otherwise state the next exact subject assertion under its predicate.

Infer no project designation from system recognition, affectedness, familiar wording, a system-role label, or shared realization. If the decision needs the unsupported compound project-selection truth, preserve missing-substrate[project-selection-conjunction] until one constructor substrate and edition define that claim.

#Use physical grounding without cross-kind identity

Ask what physically or operationally exists, where its boundary lies, and what preserves or ends its identity. This pressure helps test a proposed system reading and reject description-only substitutes. It does not identify a system with a local system-role kind, system-role assignment, capability, Work, transformation, Method, plan, evidence, or description. Do not import BORO categories, unrestricted composition, or a new 4D record.

#Archetypal Grounding — Seven Heterogeneous Worked Cases

Each row states whether the A.1.SCR trigger actually fires. The rows are examples.

Enumeration-integrity rule. The seven rows have different subjects, kinds, relations, entry decisions, and exits. Add a later example by showing its exact decision, subject, subject pattern, route, and stop.

#Scale-free and difficult-noun recognition stress

Use the same six A.1 constructive components and acting-eligibility condition for every exact entity below. The table supplies bounded fixtures, not shortcuts or a system taxonomy. true means the supplied inputs determine satisfaction; false means a required component fails; unknown names the missing input and blocks system-dependent reliance. Evaluation creates no kind membership or neighboring claim. For the sixth component, each positive fixture below states one local larger-assembly condition and the exact fixture fact that meets it. These fixture conditions are inputs to this evaluation, not universal rules, new relation kinds, or grounds for any neighboring claim in the third column.

#Bias-Annotation

#Conformance Checklist — Practical Checks

#Common Anti-Patterns and Exact Repairs

#Consequences

The pattern makes full system recognition more useful by applying it only where identity and boundary change an engineering decision. It also makes non-system results productive: Work, Method, capability, structure, episteme, and relations can close their own questions. The cost is that the practitioner must state the decision and may need to stop when construction facts or a relation governor are missing.

#Rationale

The smallest reusable repair is a conditional MethodDescription, not a new kind or universal router. A.1 supplies the system-recognition predicate. A.1.SCR contributes a working situation, non-system subject result, complete-test branch, decision-bearing results, project-designation guard, and migration cases. This prevents ontology work from becoming a ritual, prevents a familiar noun from selecting an actor or project system-of-interest, and prevents a convenient neighboring referent from erasing an exact proposed-system reading before evaluation.

Extent-sensitive identity remains useful because it forces the practitioner to state what exists and survives change. Unrestricted composition and category import remain rejected. The seven cases demonstrate transfer across domains without asserting a common kind.

#SoTA-Echoing

Informative. These sources provide bounded pressure on the practitioner route. A.1 and the named subject patterns remain authoritative for kinds, relations, and pass conditions.

The conditional method assembled here—state the decision, close with an exact non-system subject assertion when possible, apply the complete A.1 test only when systemhood remains load-bearing, and use the Method described in A.1.STM for a recognized project subject only when the outside-use dependency is still missing—is a scoped FPF synthesis of these pressures, not an external consensus claim. Reopen the synthesis if A.1 changes its constructive criterion, A.6.P changes the service/access recovery boundary, A.15.6 changes project designation, or later cross-domain evidence defeats the scale-free decision method or one of its explicit stops.

#Relations

• Builds on: A.1 for the complete constructive criterion, admitted holon kinds, acting eligibility, and true | false | unknown evaluation discipline.
• Leaves directly through: A.2.2, A.3.1, A.3.2, A.3.4, A.15.1, A.15.2, A.22, C.2.1, E.18, and the exact relation pattern when systemhood is not load-bearing.
• Service/access first use: A.6.P §4.11a; A.1.SCR applies only to a separate system-dependent claim about the exact entity recovered there—an exact bearer or access-providing arrangement.
• Uses for projects: A.15.6 for the actual and intended system distinction, plan or decision designation of the project system-of-interest, separate tests of the system-role kind and assignment, project-relevant network selection, and missing-substrate[project-selection-conjunction]; A.1.STM only when the returned recognition result must re-enter the system-thinking long map.
• Uses for missing relations: A.6.RCD with exact participants, receiving use, and missing-governor[...].
• Coordinates with: A.1.CSD when a returned bearer result opens the separate question of which other Systems may undergo relevant changes; A.1.STM for the separate long-map use after recognition; and E.10 for lexical triggers.
• Does not replace: A.1, direct kind patterns, relation patterns, A.6.P, or F.18 designation recovery.

#A.1.SCR:End

#Discovering Systems That May Bear Consequences

Type: Part A practitioner discovery pattern Status: Stable Normativity: Normative unless marked informative

Plain name. Find other Systems that may change.

Governed branch. The broad head is U.System recognition under A.1. This narrower branch examines concrete change-producing possibilities for one current focus, discovers actual Systems or intended System referents that may change under those possibilities, and returns qualified claims for one named receiver. The focus governs the account's aboutness; it is not thereby the world-side changer. Any obtaining change-producing occurrence and any causal claim remain separately governed. The pattern does not recognize every candidate, establish causality, evaluate the changes, or make the receiving decision.

Primary EntityOfConcern. One exact proposed or observed focus entity whose possible or observed consequences are being investigated. The receiving decision or investigation is a neighboring use of the result. Candidate bearers remain participants in its claims.

#Practitioner Entry

Use this when. Use this pattern when proposed or observed Work, realization, operation, use, maintenance, misuse, failure, recovery, retirement, policy, or change may alter Systems omitted from the current decision or investigation, and finding one of them could change a probe, constraint, alternative, monitoring condition, explanation, or reopen decision.

Ask: Which other Systems may undergo a relevant change, through what supported relation or still-modal path, and what should the receiver do next?

First useful move. Name the exact focus and receiver. Generate a small set of concrete change-producing possibilities, trace outward through supported direct relations or explicitly modal path claims, and challenge the current boundary for a missing bearer.

First useful result. Return the smallest bounded affected-System consequence account that changes or holds open the named receiver. One qualified consequence claim and one unresolved bearer or path are enough when they lead to a probe, constraint, alternative, monitoring condition, or honest stop.

Cheap stop. Stop if the current bearer set and consequence claims already support the receiver at the declared configuration, scope, horizon, and evidence window. Also stop when an exact non-System finding or missing relation blocks the next claim; return that finding to its direct owner instead of inventing a System.

What goes wrong if missed. A familiar participant list becomes the boundary of inquiry, a possible path is reported as an obtaining relation, a scale label stands in for a constructed whole, or unlike changes disappear inside one aggregate. The receiver closes while a cheap observation or alternative could still have changed it.

What this buys. The practitioner gets a reviewable set of possible bearers, relation-status claims, changed characteristics, evidence limits, and next probes without importing a full domain impact, risk, due-diligence, or assessment procedure.

Not this pattern when.

• If one proposed entity must first be tested as a U.System, use A.1.SCR.
• If the current question is an already named direct relation, use its A.6 governor.
• If the receiver relies on a causal effect, intervention, or counterfactual claim, use C.28 for that claim.
• If the current question is comparison or choice among configurations, use C.11.CRC and C.11 after the needed bearer claims exist.
• If the domain already has a qualified discovery Method with its own quantities, thresholds, evidence rules, and authority, use that Method; use A.1.CSD only for the shared early discovery result.

#Precision Restoration

Affectedness creates no AffectedSystem, ConsequenceBearingSystem, AffectedSystemRole, ImpactRelation, U.Level, priority, aggregate, or decision. Use each stronger claim only under its direct owner.

#Problem Frame

A change rarely ends at the boundary drawn for its proposer. For example, material, energy, chemical, biological, information, access, exposure, load, resource, capability, institutional, and dependency paths can reach other physical or operational wholes. Some paths already obtain; others are only plausible descriptions awaiting observation.

Find enough actual Systems or intended System referents whose changed states or characteristics can alter one named decision or investigation. Living, natural, engineered, artificial, human, non-human, low-agency, and non-intelligent Systems enter by the ordinary A.1 criterion, not by their visibility or ability to answer.

Scale words do not solve the search. A constituent, containing System, neighboring whole, and later reidentified whole are relevant only through their actual construction, delimitation, direct relations, or a genuine whole-reidentification question. Consequences on several sides remain separate even when a domain calculation later compares them.

#Problem

Without a bounded discovery move, practitioners commonly:

1. stop at systems already named by interfaces, ownership, participation, contracts, or observation;
2. turn a plausible path into an asserted world-side relation;
3. treat organism, population, team, organization, society, or ecosystem words as a ready ladder of Systems;
4. force collections, places, descriptions, Methods, Work occurrences, or declared scopes into System rows;
5. combine unlike bearer, horizon, evidence, and receiver coordinates before their differences are inspectable; or
6. continue brainstorming without a decision-relative stop or next probe.

The result is either premature closure or an unbounded catalogue. Both fail to change the receiver at useful cost.

#Forces

#Solution

Discover outward from concrete possibilities, preserve the status of every relation and bearer claim, and stop at the smallest account that changes one receiver.

#Perform the Move

1. Recognize the working situation. Use A.1.CSD only when an omitted System could change a named decision, investigation, probe, constraint, monitoring condition, explanation, or reopen condition.
2. Name focus and receiver. State the exact proposed or observed focus entity, current configuration when relevant, exact receiving decision or investigation, scope, place when material, and horizon.
3. Generate change-producing possibilities. Consider intended and plausible Work, realization, operation, use, maintenance, misuse, failure, recovery, adaptation, continuing change, retirement, and later conditions that matter here. These are examples of possibilities, not a lifecycle or mandatory sequence.
4. Trace paths and challenge the boundary. Follow supported obtaining direct-relation occurrences separately from modal path claims. For a modal claim, name the proposed relation kind, candidate participants, conditions, support, and uncertainty. Then ask which Systems capable of bearing the stated change remain outside the current frame.
5. Recover relation status and holon basis. Establish every claimed world-side relation occurrence—such as part-whole, participation, dependency, crossing, or exposure—only through its direct governor. Recover an environment from one focal System delimitation, exact external referents, supported crossing relations, and the selected use; recover a delimitation or boundary through its own FPF construction and supporting facts, not as a relation occurrence. Support a containing-System claim through the exact part-whole relation and construction. A context or declared scope remains a use-bounding fact and does not by itself make a world-side relation obtain. Use exact construction facts rather than a level word. Use B.2 or B.2.2 only when current facts create a real whole-reidentification question, then inspect possible bearers on both sides.
6. Recognize or retain bearer references. Use A.1.SCR only when an actual candidate's systemhood is load-bearing. Keep a not-yet-present or unidentified bearer as an intended referent or explicit unknown inside modal content. Preserve a collection, place, scope, or other holon under its own kind or blocker.
7. Qualify each consequence claim. Name the changed state or characteristic, exact bearer, obtaining-occurrence or modal-path status, conditions, configuration, direction and magnitude cue when known, time, grounded whole/part or declared-scope coordinate when current, evidence, uncertainty, and causal status.
8. Keep cross-scale coordinates distinct. Preserve each bearer's changed state or characteristic, conditions, horizon, evidence, uncertainty, and receiving use. A later domain aggregate may be added for its own use; it does not replace the original claims or set priority by scale.
9. Connect the result. For each material claim, state whether the receiver needs a constraint, alternative, evidence-producing probe, specialist return, monitoring condition, reversible step, or explicit unresolved gap. Route a stronger claim to the pattern or practice that defines and tests it.
10. Prioritize inquiry without erasing sides. Investigate first what could reverse or constrain the receiver, what is hard to reverse, what has large uncertainty and cheap information, and what bearer/path combination is poorly observed. Keep the original coordinates visible.
11. Stop and reopen. Stop at the smallest account that changes or holds open the receiver. Record plausible missing bearers or paths, the cheapest next discovery action, and the observation, new System, changed whole, changed use, evidence, or specialist result that reopens the account.

This sequence of actions is a reasoning aid. Discovery, observation, design, comparison, and specialist inquiry may proceed concurrently and reopen one another.

#Keep Relation and Holon Status Explicit

An exact modal claim is useful because it tells the next observer what must be checked. It remains modal until the obtaining predicate is supported.

#Record the Result as One Ordinary Episteme

The account is reusable only when its C.2.1 identity and working content are explicit:

A thin account may contain one qualified consequence claim plus one unresolved bearer, path, or specialist return when those entries already change the receiver. Blank fields do not assert closure. Bearers and unknowns are participants in the ClaimGraph, not extra EntityOfConcern values. If one truthful focus cannot govern the combined claims, keep the claims local or identify several account epistemes.

#Recognition and Assurance Split

Recognition. A cold reader can find the focus, receiver, at least one possible bearer, the obtaining-or-modal status of its path, the possible changed characteristic, support and uncertainty, and the next probe or stop.

Assurance. Trust in systemhood, relation occurrence, measurement, causal effect, source reliance, comparison, and specialist result remains with the direct patterns and practices.

#Four First-Screen Situations

The same discovery action changes all four situations. Their domain Methods, quantities, evidence rules, and decisions remain different.

#Minimally Viable Worked Case: Nutrient Pulse

FeedPulsePlan-FP4 proposes a larger nutrient pulse for BioreactorOperatingSystem-BR7. The receiving investigation is ProbeDecision-PD4: choose the next observation before changing the feed setting for the next 48 hours. The plan is the account's one exact focus EntityOfConcern; the ClaimGraph examines the possible feed-operation occurrence it specifies rather than treating the plan as a physical cause. The probe decision is the account's neighboring use.

Baseline instrumentation supports one obtaining substrate-transfer occurrence from FeedLine-F2 into the reactor medium and one obtaining effluent-flow occurrence from BR7 to TreatmentTrain-TT2. Microscopy and persistence observations support the constructive recognition of individual bacterial Systems and BiofilmPatch-BP3: matrix-linked constituents, persistent assembly, whole-level nutrient-processing and shear-resistance characteristics, and actual participation in nutrient transformation establish the patch as a distinct System. The exact constituent relations used for the patch are recorded under their part-whole governors. No generic impact edge is added.

The proposed larger pulse has not occurred. The account therefore keeps four paths modal:

The account keeps bacterial, biofilm, reactor, and treatment-train characteristics separate. It does not average them into one score. Its discovery residual names an observed unattached aggregate outside BiofilmPatch-BP3. Current evidence supports treating the observed members as a collection; whether that collection also forms a whole/System remains unknown because assembly, persistence, and the kind-specific A.1 facts are unsupported. The next recognition probe images the same aggregate across two sampling intervals and records any stable assembly relation and whole-level behavior. Recover those A.1/C.13 facts before classifying it; only supported failure of a required A.1 component or condition warrants a negative System result.

The first useful result is the four-part probe: spatial bacterial sampling, image-based biofilm-coverage observation, pressure-drop monitoring, and effluent measurement. The current pulse setting remains the reversible alternative until those observations support a change. Stop when ProbeDecision-PD4 can choose that probe set and alternative and every retained modal path has a support statement, uncertainty, and reopen observation. Reopen if a new whole is recognized, the feed configuration changes, or an observation reverses one path claim.

#Bias Annotation

#Conformance Checklist

#Common Failures and Repairs

#Consequences and Reopen Condition

The pattern makes quiet and remote Systems discoverable without turning discovery into a role taxonomy or universal assessment procedure. It gives downstream work a qualified starting point: an actual bearer, an intended referent, a supported relation occurrence or modal path, a possible changed characteristic, and the evidence-producing move that matters next.

The cost is explicit uncertainty and more disciplined relation handling. Some inquiries stop with a missing System-recognition or relation fact; that stop is useful because it identifies the next observation.

Reopen the account when the focus, configuration, scope, horizon, whole/part construction, obtaining-relation support, bearer recognition, observation, specialist result, or receiving use changes. Reopen this pattern itself only if repeated cross-domain use cannot express the shared discovery move without a new genuinely transdisciplinary result.

#Conditional Consumer Boundary

The core account ends before stronger neighboring claims. Continue only when the next question is current:

For the last branch, one admissible D.1 value-frame edition is multilevel holonic consequentialism: inspect consequences for every constructively identified affected holon without automatic priority for a person, collection, or larger whole. That frame is conditional and plural under D.1. It adds no field to the A.1.CSD account. Establish any conflict, priority, or decision claim under its direct pattern.

#Rationale

A.1.SCR answers whether one proposed entity is a System. A.1.CSD begins after a focus is current and asks which other Systems may undergo relevant changes. Merging the two would burden every systemhood check with an open-ended consequence search and would confuse candidate generation with recognition.

A.1.STM locates one unsupported answer across a long dependency; C.28 qualifies one causal-use claim; C.11.CRC constructs a finite comparison. None generates the bounded bearer/path/change account at comparable effort. A.1.CSD therefore stays a thin sibling in the A.1 family and returns each stronger claim to its direct owner.

The result remains an ordinary C.2.1 episteme because the recurring need is a reusable set of qualified claims, not a new world-side kind or relation. One focus gives the account identity; several bearers give it content.

#SoTA Echoing and Source Use

Each row distinguishes a descriptive result, constructive Method, normative premise, or institutional preference; it retains only the action supported for this use.

These sources converge on path tracing, boundary challenge, proportional inquiry, qualified uncertainty, and reopening. Their taxonomies, normative ends, calculations, evidence thresholds, and authority do not converge and are not imported.

#Relations

• Builds on: A.1 for admitted holon and System recognition; C.2.1 for the account episteme; A.14, B.1, B.1.2, and C.13 for exact relations, wholes, collections, delimitation, crossings, and constructive grounding.
• Uses conditionally: A.1.SCR for a load-bearing bearer-recognition question; B.2 and B.2.2 only for genuine whole reidentification; A.6.RCD for a missing direct-relation governor; A.10, C.27, C.28, C.29, C.30.ILC, C.11.CRC, C.11, and the D-family only for their exact neighboring questions.
• Supplies: a bounded affected-System consequence account to a named decision or investigation. Current SYSE.17 adds engineering possibilities, project/configuration inputs, engineering returns, assurance interfaces, and specialist authority boundaries.
• Does not replace: domain impact, risk, due-diligence, value-engineering, ecological, safety, legal, medical, economic, governance, policy, participation, or facilitation Methods; System recognition; causal support; comparison; assurance; authority; or decision.

#A.1.CSD:End

#Using the System-Thinking Long Mantra

Type: Part A practitioner application pattern Status: Stable Normativity: Normative unless marked informative

Plain name. Use the system-thinking long mantra.

Mint or reuse. This pattern introduces no U-kind, relation kind, project kind, case kind, map kind, or record kind. A.1.STM is a PatternID. Long mantra and attention map are Plain names for a repeatable reminder and its readable dependency display.

#Practitioner entry

Use this when. Use this pattern when a project team has, or is choosing, one common project system-of-interest but cannot tell which answer is missing on the map from the change expected outside that system to the work and systems that make or change it, and onward to the work and systems that make or change those builders. Use it also when a local result has no supported next fact connecting it to production or change, release, runtime use, or that outside change.

First useful move. Name the final result that matters now: a release, runtime use, or specific change expected outside the project system-of-interest. If a local result is current, say exactly what it is about and name the next supported fact needed to connect it to production or change, release, runtime use, or that outside change. Read backward only far enough to name the first answer that is absent, stale, disputed, or unsupported. Then state that exact question and use the one subject pattern whose Use this when accepts it as a locator for the required definition or constraint.

Memorable reminder.

Start with the change needed outside the system the project is about. Choose that system and its boundary by that use; only then choose its inside. Ask how it will be made or changed, who or what can do that work, and what must make or change those builders. Read backward to the first unsupported answer. Follow real work and changes forward; for each local result, name the supported next fact that connects it to production or change, release, runtime use, or the outside change—or stop where that fact is missing.

This reminder is the Plain long mantra. Section 4 gives the working steps for using it.

Not this pattern when. If the current question is already one system-recognition, project designation, service/access, architecture, Method, Work, transformation, TFS/network, causal-use, evidence, or assurance question, use that direct pattern and stop there. Do not traverse the long map merely because a project mentions a project system-of-interest.

What this buys. The practitioner returns one located gap, one subject pattern, and one next question or action—or a truthful stop.

#Problem

A project can get every nearby statement locally right and still lose the long dependency. One team improves a component, another produces a builder, and another measures operation, yet nobody can show which supported relation carries those results toward use of the project system-of-interest. The gap is often hidden by a diagram arrow, the word creates, or a calendar sequence.

The opposite failure is to turn the reminder into a universal route. Then project Work becomes a network, a case becomes a slice type, a planned system is treated as already existing, and every arrow appears to be the same relation. A.1.STM keeps the long question visible while every local truth stays with its subject pattern.

#Forces

#The attention map

Keep these regions visible. They are questions and result locations, not stages or fields of a record.

Read backward across these regions to justify a needed result and locate the first unsupported answer. This is logical attention, not didactic order, a WorkPlan, dated Work order, U.Transfer, or transformation direction.

Trace forward through independently grounded facts: performer systems and assignments, dated Work, changes of continuing referents, production participation, identity inception, completion, later use, and environment-side change. In the runtime region, identify the exact environment or input referent and its A.3.4 change separately from the direct causal, interaction, functioning, participation, or Work claim for the already existing project system-of-interest; add work-facing assignment, Method, or Work only when those claims separately obtain. These facts may occupy several TFS or network members. Shared identity or temporal adjacency connects none of them without a directly governed relation occurrence and its endpoint bindings.

#Solution

1. Choose by the final result. Name the release, runtime use, or specific change expected outside the project system-of-interest. If a local result is current, say exactly what it is about and ask which supported fact connects it next to production or change, release, runtime use, or that outside change. If another long mantra better matches the final result, leave A.1.STM.
2. Place supported answers and the current scope. Put only answers supported by named facts, observations, decisions, or results in the matching regions. At project level, name the admitted E.18.NET selection and its exact use question; before admission, keep a Plain provisional map and name the missing member, relation occurrence, or endpoint binding. In neither case call the network project Work. For one current case, state only four things in ordinary language: the exact subject or claim; the bounded references and direct claims needed to answer this closure question; the separately governed closure basis; and one named downstream receiving use that remains outside the closed case. Use A.15.6 to choose any technical reference form the case actually needs; do not copy those forms here. Keep plans, descriptions, Methods, Work, systems, changes, relations, evidence, and assurance distinct; do not turn this placement into a dossier or record schema.
3. Find the first unsupported dependency. Read backward from the final result and choose the earliest missing, stale, disputed, or unsupported answer that blocks the next dependency. First means logical firstness, not calendar firstness.
4. Use one subject pattern. Perform the working move described by the pattern whose Use this when accepts the missing question, and retain the resulting assertion or named stop. Do not copy its Solution into this pattern.
5. Return only what the next use needs. Put the answer back in the map. Select an E.18.NET network only when its members, relations, constraints, use frame, and endpoint bindings are grounded. Usually return the individual answers. Select another A.22 structure only when one named later task must reuse their organization as one thing and all four identity discriminators pass. Otherwise keep the direct plurality or Plain provisional map.
6. Trace forward and test. Follow actual Work, production and identity facts, later changes, participation in use, and environment-side changes through their subject patterns. Repeat for each relevant builder branch. Bind evidence to the claim it supports; stop at the first unsupported direct link and reopen only the smallest affected earlier answer.

Four orders remain separate throughout: the order used to teach the map; the logical dependency read backward; planned or actual Work order; and the subject relations that obtain. One ordering establishes none of the others.

#Minimal worked use

A pump-modernization project needs PumpUnit-3 to restore reliable water delivery in its operating environment. The plan designates the already existing pump as the project system-of-interest. A.1 recognition, that designation, any SystemOfInterestSystemRole, and any system-role assignment remain four separate questions.

The team already supports the outside-use hypothesis and a controller-architecture choice. Reading backward exposes the first unsupported answer: can the planned controller result become an actual system ready for installation? The team leaves A.1.STM for the subject patterns. It identifies ControllerSubassembly-7 and other pre-existing materials as the continuing subjects of any A.3.4 changes; recovers each actual fabricator's A.13 core; independently admits fabrication Work under A.15.1; and uses A.15.PROD separately for production participation, controller identity inception, and production completion. This minimal case consumes no exact assignment-bound attribution, so it does not open F.6. It does not describe transformation of the controller before the controller exists.

For the controller-production case, the subject and closure basis are explicit. The case closes only when the independently governed identity-inception, completion or readiness, evidence, and decision claims needed here pass. The named downstream receiving use—installation and later operation in PumpUnit-3—is visible but remains outside the closed case.

At project level, the team may select TFS members concerning controller production, pump modification, qualification, and pump operation together under E.18.NET only after each member is independently identified and the required production, installation, participation, use, or feedback occurrences and endpoint bindings obtain. Until then the network remains a Plain provisional explanation with the missing link named. Actual facts are then traced forward from fabrication Work and changes, through controller inception and pump modification, to later pump operation. When runtime use is claimed, the already existing PumpUnit-3 and its direct participation claim remain separate. If dated runtime Work is claimed, recover every performer's A.13 core and independently admit the occurrence under A.15.1; add F.6 only when precise assignment-bound attribution is also current. Keep either actor-side claim separate from any A.3.4 change of one exact continuing delivery-side environment or input referent; the expected reliable-delivery hypothesis alone establishes neither actuality. A failed relation or missing binding stops that claim without erasing the valid local results.

If later operation shows that reliable water delivery depends on an upstream reservoir-control assembly outside the proposed PumpUnit-3 boundary, the team reopens the outside-use, project designation, and boundary hypotheses before revising the architecture and network selection. It does not preserve the old inside merely because Work has already begun.

#Direct exits and near misses

#Recognition stress boundary

Before a map relies on an acting system or changed-system boundary, use the one A.1 recognition architecture through A.1.SCR. Its heterogeneous stress cases cover an engineered pump, an animal, a human, a software-realized AI agent, a robotic AI agent, a coordinated collective and roster near miss, the Moon and a tide bearer, plus the exact proposed-system readings SutureControl-M17, GameSessionWhole-GS204, and InternetAccessArrangement-CA17 beside their ordinary subject-pattern readings.

A.1.STM consumes only the returned recognition result. It does not repeat the six-component test, replace the exact entity with a convenient neighboring bearer, infer a system-role assignment from causal participation, or infer Method, Work, transformation, promise, permission, project designation, or a system-role kind from systemhood.

#Conformance checklist

#Common anti-patterns

#Consequences

Benefits. Teams can locate a missing long-range dependency. Local results remain usable, builder recursion remains visible, and a missing relation stays an explicit stop rather than becoming a convenient arrow.

Costs. Practitioners must name the final result, keep several kinds of order apart, and return to subject patterns for local truth. A provisional map may remain incomplete for a long time.

Limits. This pattern does not identify a system, designate a project system-of-interest, select architecture, admit Work or transformation, close a case, identify a TFS network, or establish evidence or assurance. It only governs how a practitioner uses the long attention map to find and return the next result.

#SoTA-Echoing

Informative. These sources provide bounded pressure on use of the long attention map. The named subject patterns remain authoritative for kinds, relations, participants, and pass conditions.

The reconciliation of long-mantra attention, subject-qualified results or blockers, minimal case closure, and E.18.NET recursion is a scoped FPF synthesis of these pressures, not an external consensus claim. Reopen the smallest affected clause if practitioner testing cannot distinguish the map from the Solution, a WorkPlan, or CGUS; if outside-before-inside or system-of-interest practice changes; if E.18.NET cannot express recursive builders without false membership; if a case exposes a missing runtime, closure, relation predicate, or link; or if creator graph, function/role, service, target-like system wording, fixed sequence, or a universal contribution edge again becomes load-bearing.

#Rationale

The useful inheritance from systems-thinking mantras is the connected attention span: expected outside change and project-system boundary, separately grounded runtime transformation and participation, internal organization, making or changing the system, and recursive builders. FPF preserves that span while rejecting a single algorithm, a creator graph ontology, word-induced systemhood, and a universal route. Project-level network placement and a minimal subject- or claim-centred case placement keep the span usable without identifying project, network, case, or record. The smallest reusable account is therefore a thin use pattern beside A.1, not an expansion of system recognition or architecture.

#Relations

• Builds on: the Plain long/local boundary in Preface; A.1 and A.1.SCR for exact system recognition; and A.15.6 for project system-of-interest designation, actual project Work, and subject- or claim-centred case recovery.
• Coordinates with: C.32.P2S and the C.30 family for outside-use-to-architecture reasoning; A.3.4 and the patterns for exact dynamics, interaction, causality, participation, assignment, Method, and Work claims in runtime change and system participation; A.2 and A.2.1 for system-role-kind interpretation and assignment; A.3.1, A.12, the A.15 family, A.15.PROD, A.15.5, and A.21 for Method, Work, production, identity, readiness, and gates; E.18 and E.18.NET for TFS and project-level network selection; A.15.6 for the minimal case recovery and closure boundary; A.10 and B.3 for evidence and assurance; A.1.CSD when the missing answer is which other Systems may undergo relevant changes; and C.28 only for actual causal-use claims.
• Optional demonstration: A.22.CGUS may govern a separately admitted demonstrative unfolding slice. Ordinary use of this long mantra requires no CGUS, F.17 row, durable card, or registration.
• Does not replace: any direct pattern named above. A.1.STM returns that pattern's result or stop to the attention map and defines no world-side predicate.

#A.1.STM:End

#System-Role Kinds and Assignments

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

#Use This When

Plain name. Work-facing system classification and assignment.

Use this pattern when one admitted U.System can contribute to different work or functioning without becoming a different system, and the current claim must say either:

• which exact work-facing kind the system counts under now; or
• which system-role assignment actually obtains.

A system here is any individual independently admitted by A.1. It can be a person, team, organization, service, organism, or non-human technical object. The SystemRole head in a name such as ReviewerSystemRole says that candidates are systems.

Typical moments:

• the same pump counts as a cooling circulator in plant operation and as a test article in qualification work;
• a project must decide whether Alice counts as a reviewer in one review slice;
• a relied-on claim says that a system holds a named system role but leaves the assignment occurrence unclear;
• ordinary wording says that a publication, method, capability, or relation participant “plays a role”, although the direct relation is still hidden;
• a proposed “part of a role” may instead be another kind, a relation among kinds, an assignment-state predicate, a capability condition, a responsibility or commitment relation, or a method or Work structure.

Primary EntityOfConcern. One exact local U.Kind whose candidates are U.System individuals and whose operative membership condition distinguishes a stable, assignable, work-facing contribution. C.3 recovers the kind through that candidate domain and condition, a useful member/non-member boundary, and a continuity rule. A practice or source reference may locate the definition or prompt comparison; it does not identify the kind. Such a kind is called a system-role kind. Assignment is a neighboring direct relation, not part of the kind.

Primary working reader. The first reader is an engineer-manager, analyst, or FPF author who must keep system identity stable while making classification and assignment inspectable. A later reader must be able to recover the kind's candidate domain, work-facing membership condition, member/non-member boundary, continuity rule, declaration edition, candidate and slice, useful definition provenance, and any separately obtaining assignment and Work attribution.

First useful move. Start with the ordinary conclusion: “Alice counts as a reviewer for this submission” or “PumpUnit-3 is assigned as cooling circulator for this operating episode.” For classification, name the local system-role kind and evaluate the candidate with one KindSignature under C.3.2. Add a U.SystemRoleAssignment occurrence only when holding or assignment identity is actually claimed.

Concern-word boundary. Concern is Plain reader- or viewpoint-facing wording. It does not admit U.Concern or replace the exact EntityOfConcern, viewpoint episteme, kind, assignment, or receiving relation needed by the claim.

What goes wrong if missed. One label absorbs kind identity, classification, holder, assignment, capability, responsibility, and Work. Or every contribution is forced into a system role even when the real claim concerns evidence use, a relation participant, a declaration slot, or ordinary wording. In both cases readers cannot tell what exists, what merely describes it, and what actually happened.

What this buys. Systems retain their identities while work-facing classifications and assignments change. Membership is testable from the system features named by the membership rule rather than labels or circular hierarchy edges. Practices and sources may reuse one kind or define different kinds; comparing their exact distinctions decides which. Ordinary contribution wording can stay readable without manufacturing an ontology.

Not this pattern when.

• Use A.2.1 when the current object is a U.SystemRoleAssignment species or occurrence and its participant, predicate, or identity law matters.
• Use A.2.2 for capability and A.2.5 for assignment state.
• Use A.2.7 for substitution, incompatibility, bundle, qualification, or another admitted relation among system-role kinds.
• Use A.15 and its neighbors for method admission, planned Work, performed Work, and Work attribution.
• Use E.24.UK when a local system-role kind is proposed as a durable public FPF U-kind.
• Use E.10.ROLE when the source word role is ambiguous. If the recovered meaning is relation participation, a declaration place, an interface place, or a representation position, continue with A.6.RSIR.
• When an episteme rather than a system is current, recover its direct use, evidence, publication, external-rule, currentness, or reliance relation through the relevant subject pattern.

#Problem Frame

One system can contribute in several ways while remaining the same system. PumpUnit-3 remains the same pump when it counts under CoolingCirculatorSystemRole for plant operation and under TestArticleSystemRole for qualification. A person remains the same person while counting under author and verifier kinds in different slices and holding different assignments.

These are local typed distinctions, not durable universal kinds. Each system-role kind has U.System candidates and a condition that distinguishes the stable, assignable contribution in question. C.3 also requires a useful member/non-member boundary and a continuity rule. Practice or source provenance helps readers find and compare the definition but decides neither sameness nor difference. A KindSignature edition states how candidate features are evaluated. A C.3.2 judgment then answers whether one System counts under that kind in one slice. A separate assignment occurrence says that a System is assigned under its declared U.SystemRoleAssignment species.

Ordinary language also uses role to mean contribution or position. A design method can use a standard publication as a source for a constraint; a report can participate in an evidence relation; and a value can fill a relation slot. Those useful claims make neither the episteme nor the slot filler a system-role kind or assignment participant. The current relation must be recovered before the wording carries an FPF technical claim.

#Problem

Without this pattern:

1. one system's changing contributions are modeled as changes of system identity;
2. a familiar label or taxonomy row is treated as a kind and as proof of membership;
3. kind identity and the membership criterion are treated as the same thing;
4. an assignment is used as a family-wide membership rule, or classification is used to manufacture an assignment;
5. the holder, kind, assignment interval, capability, responsibility, and Work are compressed into one record;
6. matching labels across local practices, sources, or editions are treated as identity or permission for reuse;
7. proposed subkind edges or extension rows create their own membership evidence;
8. ordinary role wording turns epistemes, slots, positions, or interfaces into system-held roles.

#Forces

#Solution

Use an exact local U.Kind when U.System candidates need one stable, assignable, work-facing membership distinction. Recover the kind through the candidate domain, operative condition, useful member/non-member boundary, and continuity rule. Keep practice or source provenance as a locator and comparison cue. Give a live technical name the SystemRole head, such as ReviewerSystemRole or CoolingCirculatorSystemRole. Do not introduce U.SystemRole; the concrete value is already a local U.Kind under C.3.

Then keep four moves separate:

1. identify the local system-role kind;
2. declare or select the KindSignature edition used for membership;
3. evaluate one system, kind, signature edition, and slice under C.3.2;
4. add a directly declared U.SystemRoleAssignment species and occurrence only when an assignment actually obtains.

Capability, assignment state, method admission, performed Work, responsibility, commitment, permission, authority, evidence, reliance, and publication remain direct neighboring claims.

#Recognize a System-Role Kind

A local kind is a system-role kind only when all of these conditions hold:

1. its candidate ValueKind is U.System;
2. its operative membership condition states the stable, assignable, work-facing contribution and uses directly governed candidate features;
3. at least one intended member and one relevant non-member or boundary case make the distinction testable;
4. its continuity rule says which changes preserve that distinction and which require another kind; and
5. its KindSignature does not treat a label, taxonomy row, description, assignment record, classification judgment, extension row, or proposed U.SubkindOf edge as the feature by form.

The kind asks what continuing distinction classifies candidate systems. A particular C.3.2 judgment asks whether one system satisfies the current signature now. Practice or source provenance shows where to inspect the definition; it neither creates nor splits the kind. CoolingPumpKind is not thereby a system-role kind. Its identity can be a physical or functional pump distinction rather than an assignable work-facing contribution. ShortAssignmentKind, if declared to classify assignment occurrences by duration, is also not a system-role kind because its candidates are assignments rather than systems.

#Evaluate Membership without a Circular Shortcut

Each membership clause names the candidate feature's subject pattern, predicate or governed feature, applicability, dependencies, and slice. The classification has four explicit inputs:

J(candidateSystem, systemRoleKind, kindSignatureEdition, contextSlice)
  -> true | false | unknown

An assignment may be one feature only when the local KindSignature explicitly uses that independently obtaining assignment predicate. There is no family-wide rule that assignment means membership. The judgment being computed, a broader-kind judgment, an extension row, or the proposed U.SubkindOf occurrence cannot be a premise of the same judgment.

Missing a required feature or dependency yields unknown, not false. Evidence supports a claim about the governed feature; it does not create that feature or the membership result.

Every U.SubkindOf proposal evaluates the aligned narrower and broader signatures independently for the same candidate and slice. Admit the order only when the C.3.1 monotonicity condition holds. The edge records an already established implication; it never produces either classification judgment.

#Keep Kind Identity, Declaration, and Extension Separate

The system-role kind is not its KindSignature, taxonomy episteme, reference scheme, classification judgment, or KindExtension. Same-kind continuity across declaration editions requires the C.3.1 comparison of candidate domain, operative membership distinction, member/non-member boundary, and continuity rule. A compatible criterion or scheme edition can preserve the kind while later judgments cite the edition actually used. A changed source or practice triggers that comparison but does not decide it.

An old role taxonomy or scheme can help recover the candidate domain, membership distinction, boundary probes, continuity rule, or provenance of the current definition. Its label or identifier does not decide sameness. A selected BoundedModelUseStructure can qualify one receiving interpretation when that independently established organization matters; it is designated in the receiving assertion or use and is stored neither on the kind nor as an optional participant of a generic assignment or kind relation. A genuinely structure-dependent relation species instead declares the structure as a required participant, uses the stronger predicate, and states the resulting occurrence-identity law.

Use A.1.1 before citing that structure. Select BoundedModelUseStructure only when exact model applicability, actual model use in assigned Work, fixed-content expression coherence, exact applied constraints, and one named selection-use frame jointly change the receiving decision. If the direct kind, relation, assertion, or Bridge already answers the question, stop there; neither a model-use label nor a wish for more background selects the structure.

#Admit Only Exact System-Role-Kind Domains

U.Kind is too broad as the assigned-kind participant domain of an assignment species. Each bounded system-role vocabulary declares one local domain whose candidates are local kinds satisfying the recognition conditions above. For example:

JournalReviewSystemRoleKindDomain : U.Kind
  definitionProvenance: JournalReview-2026 (comparison cue only)
  candidateValueKind: U.Kind
  criterion:
    the candidate kind has U.System candidates, a stable assignable
    work-facing membership condition, useful boundary probes, and
    a continuity rule recovered under C.3

A direct assignment species uses that local domain as the ValueKind of its declaration-local AssignedSystemRoleKindSlot. The slot therefore rejects CoolingPumpKind, ShortAssignmentKind, and arbitrary local kinds. This is local C.3 typed use, not admission of U.Kind as a durable public root.

#Assignment Boundary

A.2.1 defines the U.SystemRoleAssignment family. The family contains directly declared relation species rather than one permissive universal signature. Every species declares:

• HolderSystemSlot : U.System;
• a declaration-local AssignedSystemRoleKindSlot whose ValueKind is one exact local system-role-kind domain;
• any additional real participants needed to distinguish that species; and
• its own obtaining predicate, applicability, and occurrence-identity rule.

A simple species can declare only the holder and assigned-kind participant meanings. A stronger appointment, authorization, or work arrangement can declare another participant meaning when its actual value changes occurrence identity. The specialized occurrence itself remains a U.SystemRoleAssignment; do not keep a second generic occurrence beside it merely for projection.

An assignment occurrence begins when its predicate starts obtaining for the fixed participants, continues over the maximal uninterrupted predicate-true interval, and ends when a participant changes or the predicate ceases to obtain. A taxonomy episteme, reference scheme, KindSignature, assertion, or interval description can interpret or describe the claim without becoming another world-side participant.

Assignment does not prove classification unless the kind's signature uses that independently obtaining relation as a feature. Classification does not create an assignment. Neither one proves capability, agency, responsibility, authority, commitment, permission, functioning, method enactment, or performed Work.

#Relations around the Kind and Assignment

Select only the objects needed by the current claim. None of these values is a “part of the role”.

SystemRoleKindDescription is an F.4 description episteme whose exact EntityOfConcern is one system-role kind. An episteme about an assignment or a relation among kinds has that assignment or relation as its EntityOfConcern instead.

#Recover Contribution Wording before Formalizing It

The phrase “the role of X” often means that X contributes to a use. Apply E.10.ROLE first. If X is an admitted system and the claim needs a work-facing classification, recover the local system-role kind and C.3.2 judgment; add an assignment only when holding is claimed. Otherwise keep X in its actual kind and name the direct relation or declaration place.

Use these recognition probes to identify the relation in the current claim. If no direct relation can yet be named, return the exact missing-governor rather than minting a system-role kind.

#System-Role Vocabularies and Relations among Kinds

A system-role-vocabulary or taxonomy episteme may state local kind names, declarations, and selected relation claims under an effective reference scheme. Each live kind needs the C.3 distinction that lets readers recover it; each judgment cites its actual signature edition. An assignment claim separately requires an obtaining A.2.1 relation.

Use A.2.7 to state one selected SystemRoleKindRelationStructure over exact local system-role kinds and admitted relations among them. A receiving use can cite an assertion about substitution, incompatibility, bundle, qualification, or another residual relation alongside separately stated assignments, state, capability, and Work. Systems and assignments are not participants of the kind-relation structure.

Algebraic, graph, matrix, embedding, or neural representations are mathematical lenses over that selected structure when a project declares the lens use. They neither create the kinds nor make a relation obtain.

#Reduced Use and Stronger Claims

Ordinary “Alice is reviewer” or “this component plays a control role” wording can remain Plain when no decision, attribution, admission, or reliance depends on another technical distinction. Do not materialize a kind, judgment, or assignment merely to decorate the sentence.

When a stronger claim appears, add only the needed object:

• the local kind and judgment when classification matters;
• the assignment occurrence when who holds what and when matters;
• the direct state, capability, method, Work, responsibility, commitment, permission, evidence, reliance, or publication relation when that relation carries the claim;
• the exact C.3.3 kind relation and, when local meanings differ, F.9 relation needed for cross-local use, without merging the kinds or creating assignments.

The earlier Plain sentence is not evidence for a stronger claim.

#Archetypal Grounding

#Reviewer Membership and a Non-Circular Subkind

The JournalReview practice records one local kind under C.3. The source label locates the definition; the kind itself is recovered through its system-candidate domain, substantive-review condition, boundary probes, and continuity rule:

ReviewerSystemRole : U.Kind
  definitionProvenance: JournalReview-2026 (comparison cue only)
  candidateValueKind: U.System
  operativeMembershipDistinction:
    can supply a substantive review judgment that meets the current
    JournalReview acceptance conditions
  intendedBoundary:
    a system that applies those conditions is a member; a report or a
    system that merely comments without applying them is not
  continuityRule:
    continue the kind only while that candidate range and distinction continue
KindSignature@ReviewerSystemRole/e3:
  EntityOfConcern: ReviewerSystemRole
  candidateValueKind: U.System
  membershipCriterion:
    one current A.2.2 capability instance has the candidate system as holder,
    names substantive-review Work or its review-judgment result class,
    and satisfies its declared envelope, measures, and currentness;
    the current JournalReview capability-fit predicate confirms the submission,
    review-phase, and judgment-quality conditions for this slice
  sliceApplicabilityConditions:
    the submission, review phase, and temporal selector
  effectiveReferenceScheme: JournalReview-Scheme-2026/e3
  assumptionsAndDependencies:
    the capability instance, currentness condition, and capability-fit predicate

The capability and fit predicate are governed under A.2.2. They are features used by the criterion, not substitutes for the kind or judgment. One application can therefore state:

J(Alice, ReviewerSystemRole, KindSignature@ReviewerSystemRole/e3, ReviewSlice-17) = true
J(Alice, ReviewerSystemRole, KindSignature@ReviewerSystemRole/e3, LaterSlice-18) = false

The later result follows only from a known failed currentness or fit condition. Ending an assignment alone changes neither judgment because this signature does not use assignment as a feature. If a dependency is unavailable, the result is unknown.

For RoboticsEngineerSystemRole U.SubkindOf EngineerSystemRole, evaluate the two aligned signatures independently for every admitted candidate and slice needed by the declared domain. Only after every defined true narrower judgment implies a true broader judgment may C.3.1 admit the relation. The proposed edge proves neither judgment. An independently obtaining robotics assignment also proves neither judgment unless the relevant signature explicitly uses it as a non-circular feature.

#Pump in a Cooling Loop

CoolingCirculatorSystemRole names a local kind whose candidates are admitted systems. Its membership condition requires the governed circulation features needed for the plant-operation contribution; member/non-member probes and the continuity rule expose the boundary. PlantOperations-2026 locates the current definition but does not identify the kind. PumpUnit-3 is judged against that exact signature edition and slice; the judgment does not change pump identity.

When the plant also claims an assignment, it uses a directly declared species:

PlantCoolingSystemRoleAssignment : U.SystemRoleAssignment
  HolderSystemSlot: U.System
  AssignedSystemRoleKindSlot: PlantOperationsSystemRoleKindDomain
  predicate:
    the holder is selected for the assigned plant-operation contribution
    under the declared operating conditions

PlantCoolingAssignment@PumpUnit3:
  HolderSystemSlot: PumpUnit-3
  AssignedSystemRoleKindSlot: CoolingCirculatorSystemRole
  assignmentInterval: [2026-06-01, open]

The interval is assertion content about the known extent; the occurrence continues only while the species predicate obtains without interruption for the same participants. PlantOperationsSystemRoleVocabulary-2026, its reference scheme, and the relevant signature can be cited as interpretation evidence. They are not extra assignment participants.

Closing the open interval later refines the same occurrence description when uninterrupted identity is preserved; the stated interval neither makes the relation obtain nor becomes another participant.

The assignment proves neither circulation capability over every operating region nor performed circulation or maintenance Work. Those claims use A.2.2, A.15.1, and the applicable Method, transformation, measurement, and evidence relations.

#A Standard Used in Design Work

An engineering team uses RFC 9110 while designing an HTTP service. Keep these claims separate:

1. DesignTeam-2 independently counts under ProtocolDesignerSystemRole in the current slice when its signature criterion is satisfied.
2. One design-assignment occurrence may obtain as an instance of a declared U.SystemRoleAssignment species.
3. The RFC publication is the source episteme in the direct source-use or external-rule relation selected by the design claim.
4. Recover DesignTeam-2 as the exact actual performer through A.13, then let A.15.1 independently admit the dated design Work. Because this case expressly says the Work was performed under the exact design assignment, F.6 afterward establishes that relation through the same obtaining A.13 assignment; F.6 identifies neither assignment nor performer, and failed attribution would leave the Work intact. The Work may separately produce a MethodDescription or SystemDescription only through the applicable production claim.

#The Same Label in Two Local Practices

An editorial-review practice and a safety-assurance practice can each use ReviewerSystemRole. Compare their exact C.3 definitions before deciding whether one kind continues. In this case the safety-assurance condition admits a materially different contribution and member/non-member boundary, so two kinds are present. The practice names help locate those definitions; a shared label, vocabulary source, or reference-scheme spelling establishes neither sameness nor a Bridge.

Suppose a staffing dashboard proposes u-reviewer-display: show assignments from both practices in one Reviewer column. First recover the two exact local kinds and any F.17 cells needed by the displayed expressions; then establish only the C.3.3 kind relation and F.9 local-sense relation that the display actually consumes. State a separate C.2.1 bounded-use assertion with direction d-safety-to-editorial-display, rule r-preserve-reviewer-differences, and tolerance t-shared-label-only, plus polarity and effective scheme. The rule keeps the practices' admission, independence, evidence, and completion fields separate and tolerates only the shared display label.

Current A.10 provenance and RelianceDisposition=pass can support that display use. They do not justify substitution between assignments or merge the two kinds. If an actual named assurance claim about that use is current, only its B.3 result can support that bounded assurance use; a non-positive disposition stops or narrows it. Consequence alone creates no assurance claim. A Bridge Card can package the Bridge, bounded-use assertion, evidence, and disposition, but it grants no assignment, eligibility, capability, use suitability, or performed-Work inference. A selected BoundedModelUseStructure is cited only in the receiving use whose interpretation it changes.

#A Relation Participant Slot Named role

An external notation may call one relation position role. Apply E.10.ROLE and A.6.RSIR to recover the participant meaning and declaration-local SlotKind. Its ValueKind is the participant kind. The external label creates neither a system-role kind nor an assignment. A System participates in the relation as declared; it holds a system-role assignment only through a separate occurrence of a declared assignment species.

#Bias Annotation

#Working Guidance

1. Identify the candidate and confirm its independent A.1 admission as U.System.
2. Recover the local kind by saying which systems can count, which work-facing condition separates members from relevant non-members, and what changes preserve that distinction. Record practice or source provenance only when it helps find or compare the definition.
3. Declare or select the exact KindSignature edition and its direct governed feature criteria.
4. Evaluate the candidate, kind, signature edition, and slice as true, false, or unknown.
5. Add an assignment only when an occurrence of a declared assignment species actually obtains.
6. State each claim about state, capability, Method, Work, responsibility, commitment, permission, authority, evidence, or reliance through the pattern that defines or constrains it.
7. Evaluate every subkind proposal from independently obtained aligned judgments; never use the proposed edge as a membership premise.
8. For cross-local use, keep both kinds and their assignments distinct and establish only the C.3.3 kind relation, F.9 local-sense relation, and bounded-use claim actually needed.
9. If the source uses role for another object, apply E.10.ROLE and continue with the recovered subject pattern; stop at missing-governor when no relation is yet admitted.

#Conformance Checklist

#Common Anti-Patterns

#Consequences

#Rationale

System-role kinds solve a local classification problem. System-role assignments solve a relation-occurrence problem. The pump does not become another system because its contribution changes, and a kind does not become an assignment because one system currently counts under it.

The architecture therefore keeps these levels separate:

1. the local system-role kind, its candidate domain, work-facing membership distinction, boundary probes, continuity rule, and useful definition provenance;
2. the KindSignature and one C.3.2 judgment over a system and slice;
3. any directly declared U.SystemRoleAssignment occurrence;
4. direct neighboring relations for state, capability, Method, Work, responsibility, commitment, permission, authority, evidence, reliance, description, and publication.

Fields in a SystemRoleKindDescription belong to the description episteme. Proposed “parts” repeatedly resolve into other kinds, relation predicates, assignments, Method or Work structures, or parts of description epistemes. The useful structure is the exact relation structure governed by A.2.7, not role mereology.

Semantic locality needs no universal context participant. C.3's candidate domain, operative membership distinction, boundary probes, and continuity rule recover the kind. A practice or source reference locates the definition and warns where comparison may be needed; it is not an identity participant. An assignment species declares only its real participants. A receiving assertion or use can cite a selected model-use structure when that structure actually changes interpretation.

#SoTA-Echoing

SysML is not used as a SoTA authority or lineage here. A modeling notation does not decide the identity of a system-role kind, classification judgment, assignment occurrence, participant slot, responsibility relation, or Work.

#Relations

Builds on: A.1 for system admission; A.1.1 for selecting a BoundedModelUseStructure only when its complete decision-relevant relation organization, applied constraints, and named selection-use frame are current; C.3, C.3.1, and C.3.2 for local kind identity, declaration, classification, extension, subkind, and continuity; A.6.0, A.6.5, and A.6.REL for assignment declarations and occurrences; C.2.1 for interpretation and assertion epistemes.

Governs with: A.2.1 for system-role assignments; A.2.2 for capability; A.2.5 for assignment state; A.2.7 for relations among system-role kinds; A.15 and F.6 for Method-Work alignment and attribution; F.4, F.5, and F.18 for description and naming.

Crosses locality through: C.3.3 for exact local kinds, F.9 for relations between exact F.17 cells, and A.6.9 for ambiguous sameness wording across local boundaries, followed by a bounded-use assertion and current reliance when the receiving action needs them. A matching name, Bridge, card, or selected model-use structure creates neither identity nor assignment.

Keeps separate from: responsibility, commitment, permission, authority, state, capability, Method, Work, evidence, reliance, publication, external-rule, and currentness relations. Apply E.10.ROLE to ambiguous wording and A.6.RSIR only when relation participation or its declaration must be recovered.

#A.2:End

#U.SystemRoleAssignment - Contextual System-Role Assignment

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

#Use This When

Plain name. Assignment to a system role.

Use this pattern when another claim must rely on one obtaining assignment of an admitted U.System under one exact local system-role kind.

Typical moments:

• a MethodDescription names InspectorSystemRole, but no current assignment occurrence has been established;
• dated Work must be attributed through performedUnderAssignment(W, RA) and the exact assignment RA is still missing;
• the same system receives the same system-role kind during two separated episodes;
• two overlapping commissions or positions distinguish two assignments with the same holder and system-role kind;
• an appointment, installation locus, or work commission may be a real additional participant of one domain assignment species;
• a roster, configuration row, observation, decision, or evidence item supports an assignment claim without becoming an assignment participant.

Primary EntityOfConcern. One assignment occurrence whose relation species is declared directly under U.SystemRoleAssignment. Every species declares a holder participant with U.System as its domain, an assigned-kind participant drawn from one exact local system-role-kind domain, its own predicate and applicability, any real additional participant meanings, and its occurrence-identity rule. The occurrence supplies the actual participant values, including its holder System.

Primary working reader. An engineer-manager, analyst, Method author, or FPF author who must identify assignment and Work attribution without merging classification, capability, responsibility, authority, Method, Work, evidence, or publication into the assignment.

First useful move. Write the ordinary claim first: “Robot-7 is assigned as inspector for Shift-17.” Then identify the declared assignment species, the participant meanings and predicate it declares, and the participant values that satisfy that predicate in this case. Expose an occurrence reference only when another claim must distinguish or cite this episode.

What goes wrong if missed. A kind name is mistaken for an assignment, a permissive generic signature accepts arbitrary kinds, two real commissions collapse into one record, or a taxonomy and scheme become world-side participants. Work can then be attributed to the wrong occurrence while capability, authorization, and evidence hide as assignment fields.

What this buys. Simple assignments remain simple, stronger assignments retain their real participants, and every occurrence exposes its actual holder through the species-declared holder slot used by F.6. Repeated episodes are distinguishable without manufacturing a second generic assignment beside a stronger one.

Not this pattern when.

• Use A.2 and C.3.2 for the system-role kind and one classification judgment.
• Use A.2.2 for capability, A.2.5 for assignment state, and A.2.7 for relations among system-role kinds.
• Use A.3, A.15, and A.15.1 for Method, MethodDescription, Work, and enactment.
• Use F.6 for performed-Work attribution through an already identified assignment.
• Use the direct responsibility, commitment, permission, authority, access, decision, evidence, reliance, provenance, publication, external-rule, or currentness pattern when that relation is current.
• Use E.10.ROLE when the source word role has not yet been resolved; use A.6.RSIR when it means relation participation or a declaration place.

#Problem Frame

InspectorSystemRole can classify Robot-7 for one maintenance slice without any assignment occurrence. Conversely, an assignment can obtain while no Work occurs, and a local KindSignature can use or ignore that assignment when classifying the holder.

U.SystemRoleAssignment is the common relation family. It has no permissive root RelationSignature. Concrete domain species declare the participant law that their occurrences actually satisfy. A simple inspection assignment may need only the holder and assigned kind. A project-review appointment may also depend on one exact commission. The stronger occurrence itself is the assignment; it does not sit beside a weaker generic assignment with the same projection.

The holder can be any independently admitted U.System, including a person, team, organization, service, organism, or non-human technical object. Assignment establishes neither capability, responsibility, commitment, permission, authority, access, gate passage, functioning, Method enactment, nor performed Work.

Taxonomy epistemes, reference schemes, KindSignatures, assertions, and interval descriptions can interpret or describe the assignment claim. They are not generic world-side assignment participants. A selected BoundedModelUseStructure belongs in the receiving assertion or use unless one separately admitted relation species makes that structure a required identity-bearing participant.

#Problem

Without this pattern:

1. a system-role kind or familiar job label is used as if it identified an assignment episode;
2. one broad U.Kind slot admits physical, functional, assignment-occurrence, and arbitrary local kinds;
3. a root signature hides different participant laws behind optional fields;
4. a strong appointment is represented as one generic assignment plus another unrelated occurrence;
5. assignments with the same holder and kind but different commissions or separated episodes collapse;
6. taxonomy, scheme, context, interval, decision, and evidence become generic participants;
7. assignment is treated as classification, capability, authorization, responsibility, or Work;
8. a storage key replaces the predicate and uninterrupted occurrence identity.

#Forces

#Solution

Declare each assignment relation species directly under U.SystemRoleAssignment. Do not give the family one universal participant signature. Every admitted species declares:

• HolderSystemSlot : U.System;
• one declaration-local AssignedSystemRoleKindSlot whose ValueKind is the exact local system-role-kind domain used by that species;
• its direct assignment predicate and applicability;
• every additional actual participant that changes the predicate or occurrence identity; and
• its occurrence-identity rule.

The HolderSystemSlot and AssignedSystemRoleKindSlot names are declaration-local SlotKinds. Their spelling does not create global slots. Their complete A.6.5 SlotSpecs state ValueKind, refMode, participant meaning, multiplicity, and any constraints.

#Simple Direct Species

A simple species has only the two common participants:

JournalReviewAssignmentRelation <: U.SystemRoleAssignment

RelationSignature:
  HolderSystemSlot: U.System, U.EntityRef
  AssignedSystemRoleKindSlot: JournalReviewSystemRoleKindDomain, ByValue

predicate:
  the admitted holder is selected to supply the contribution denoted by
  the assigned system-role kind under JournalReview assignment conditions

applicability:
  JournalReview-2026 assignment episodes

JournalReviewSystemRoleKindDomain is the exact local C.3 domain defined by A.2. CoolingPumpKind, ShortAssignmentKind, and arbitrary local kinds cannot fill this species' assigned-kind slot merely because each is a U.Kind.

#A Stronger Species Retains Its Real Participants

When an appointment, organizational position, installation locus, or work commission changes the predicate or occurrence identity, the domain species declares that participant. For example, conditional on a domain pattern already admitting ProjectReviewCommission and its appointment predicate:

ProjectReviewAppointmentAssignment <: U.SystemRoleAssignment

RelationSignature:
  HolderSystemSlot: U.System, U.EntityRef
  AssignedSystemRoleKindSlot: ProjectReviewSystemRoleKindDomain, ByValue
  ReviewCommissionSlot: ProjectReviewCommission, U.EntityRef

predicate:
  the holder is appointed under the identified commission to supply the
  contribution denoted by the assigned system-role kind

The commission is a participant because this admitted species makes it one. A decision episteme, roster row, or evidence item about the appointment is not thereby the commission or another participant.

If no current pattern admits the proposed participant kind or direct predicate, return [A.6.RCD](/generated/patterns/A.6.RCD) missing-governor for that specialized assignment. Do not hide the gap in an optional field.

#Occurrence Identity

An occurrence of a declared species begins when that species' direct predicate starts obtaining for fixed participant values. It continues over the maximal uninterrupted predicate-true interval. It ends when a participant changes or the predicate ceases to obtain. A later resumption is another occurrence even when every participant value is the same.

A context field ending in ...SystemRoleAssignmentRef uses U.RelationRef constrained to U.SystemRoleAssignment and resolves to the exact occurrence while keeping its declared species recoverable.

An assignment assertion or occurrence description can state assignmentInterval with a temporal reference, start, end or explicit open end, and continuity claim. Closing an open interval later refines the same description when world-side obtaining was uninterrupted. Missing evidence yields unknown; it does not split the occurrence. A demonstrated non-assignment interval ends it.

Keep ordinary interval content here. When a positive temporal aspect itself becomes a relied-on object—its temporal reference, validity or currentness window, duration, cadence, rhythm, or interval structure—use C.27.TA for that aspect and keep the assignment occurrence separate. Use C.27 only for the different question of whether a temporal claim is adequate.

Taxonomy, scheme, KindSignature, assertion, interval description, and selected publication form can be cited when they matter to interpretation or evidence. Only the species' declared participants and predicate determine world-side occurrence identity.

#One Strong Occurrence, Not a Generic Duplicate

If Alice has overlapping Commission-A and Commission-B, then ReviewAssignment-A and ReviewAssignment-B are two ProjectReviewAppointmentAssignment occurrences even when holder and ReviewerSystemRole match. Their commission participants and predicates distinguish them.

“Alice is the reviewer” is a readable existential projection over any qualifying occurrence. It is not a third assignment occurrence. Do not create a generic two-participant assignment beside either appointment simply to support that sentence or F.6.

Every admitted species supplies the common projection:

holderSystem(RA : U.SystemRoleAssignment) = RA.HolderSystemSlot
assignedSystemRoleKind(RA) = RA.AssignedSystemRoleKindSlot

The projection does not erase additional participants or assert that another occurrence exists.

#Assignment and Classification Are Independent

A C.3.2 judgment classifies one system under one local system-role kind for one signature edition and slice. An assignment occurrence relates participants under its species predicate. Either can be current without the other.

An assignment can be one membership feature only when the exact local KindSignature explicitly cites that independently obtaining predicate. RoboticsAssignment-1 alone makes neither RoboticsEngineerSystemRole nor EngineerSystemRole true. A later U.SubkindOf result records monotonic implication among independently evaluated judgments; it creates no broader assignment.

#Demand-Driven Materialization

Ordinary use can stop at:

During Shift-17, Robot-7 is assigned as inspector under
MaintenanceInspectionAssignment.

Expose an occurrence identifier only when a receiver must distinguish episodes, cite the assignment as a participant, compare assertions, or preserve provenance. If a required participant or the predicate cannot be recovered, lower the claim or return the exact missing governor. Never insert a dummy value or broaden the assigned-kind domain.

#Direct Neighboring Relations

Assignment-establishing world-side relations and epistemic support are not interchangeable. A constituting decision or installation occurrence affects a species only when its direct predicate says so. Evidence can support relying on the assertion without constituting the assignment.

#Performed-Work Attribution

F.6 retains one direct attribution with a comparison-only projection:

performedUnderAssignment(W : U.Work, RA : U.SystemRoleAssignment)
attributedPerformerSystem(W, RA) := RA.HolderSystemSlot

A.13 first identifies the actual performer S, and A.15.1 independently admits W : U.Work from its performance history, enacted Method, temporal extent, and containing-System relation. F.6 is needed only for a precise assignment-bound attribution—when the current use must also say exactly under which assignment W was performed. It then establishes performedUnderAssignment(W, RA) against the same assignment already used by A.13 and requires S = attributedPerformerSystem(W, RA) = RA.HolderSystemSlot. The projection exposes the assignment holder only for comparison with S; it identifies neither assignment nor performer, and a missing or failed F.6 check leaves the Work intact.

SystemRoleAssignmentSlot in F.6 accepts any admitted assignment species because its ValueKind is the family U.SystemRoleAssignment. It is not a union of a generic relation and stronger non-assignment values. ReviewWork-A can be attributed to ReviewAssignment-A, and ReviewWork-B to ReviewAssignment-B, without creating generic duplicates. Assignment does not prove that Work occurred. Work does not alter assignment identity. For source wording such as RoleEnactment, first use A.13 to identify the actual performer and A.15.1 to admit the dated Work independently. If the current use also needs to say exactly under which assignment the Work was performed, add that assignment and the separate F.6 performedUnderAssignment check. Do not create a duplicate run-time kind or occurrence.

#Source Context Shorthand

Holder#Role:Context@Window is source notation, not the assignment ontology. Apply E.10.ROLE to recover the system-role kind or another meaning. Recover the object denoted by Context and its direct relation separately. It can be an actual system or Work locus, a claim scope, or a selected BoundedModelUseStructure; these have different kinds and uses.

If one assignment species genuinely depends on a structure or locus, its direct pattern declares that participant and stronger identity law. Otherwise keep the recovered object in the receiving assertion or use; never invent a generic context participant.

#Archetypal Grounding

#Robot Assigned for One Inspection Shift

The maintenance domain declares a simple species and an occurrence:

MaintenanceInspectionAssignment <: U.SystemRoleAssignment
  HolderSystemSlot: U.System, U.EntityRef
  AssignedSystemRoleKindSlot: MaintenanceSystemRoleKindDomain, ByValue

InspectionAssignment-17:
  HolderSystemSlot: Robot-7
  AssignedSystemRoleKindSlot: InspectorSystemRole
  assignmentInterval: [2026-07-13T09:00, 2026-07-13T17:00]

The two fields designate the species participants. The interval is assertion content about the occurrence extent. MaintenanceSystemRoleVocabulary-2026, its effective scheme, and the relevant KindSignature can be cited to interpret the claim without becoming participants. Sensor capability, assignment state, inspection Method, and any performed inspection Work remain separate.

#Repeated Assignment Episodes

Robot-7 is assigned again on the next day under the same species and kind. The predicate does not obtain continuously across the two shifts, so the second shift is another U.SystemRoleAssignment occurrence. Reusing one staffing-row identifier cannot collapse the episodes.

#Motor Assigned as Drive

For a current equipment assignment, declare the species and identify its occurrence: Motor-M1 is the holder and DriveMotorSystemRole is the assigned-kind value. PumpAssembly-A remains the actual assembly System and Work locus rather than a generic context participant. If installation in that exact assembly distinguishes assignment identity, the domain species must declare a real installation-locus participant and predicate, and the occurrence must supply its actual value.

The separate claim “Motor-M1 drives PumpAssembly-A during PumpRun-17” is not established by assignment. Until a domain predicate supplies its participants, applicability, and identity, return missing-governor for the motor-drive-functioning relation. Torque capability, installation Work, pumping Work, and the assignment remain usable independently.

#DDD Model-Use Structure Changes a Receiving Interpretation

Two software contexts each use ApproverSystemRole. ApprovalService-2 can hold an assignment that obtains in the fulfilment context; name both the occurrence and its declared species. A receiving interpretation use can cite both the assignment-occurrence reference and Orders-Fulfilment-ModelUseStructure when the selected structure changes that use.

The structure was independently recovered under A.1.1. It qualifies the receiving interpretation and is not a generic assignment participant. A future species that truly depends on it must declare the structure as a required participant and state the stronger predicate and identity law.

#Two Review Commissions

Alice is independently admitted as U.System. Commission-A and Commission-B satisfy the admitted ProjectReviewCommission kind. Two overlapping ProjectReviewAppointmentAssignment occurrences have the same holder and ReviewerSystemRole but different commission participants.

ReviewWork-A is attributed to ReviewAssignment-A; ReviewWork-B is attributed to ReviewAssignment-B. “Alice is the reviewer” can remain a recognition sentence, but it does not merge the appointments or identify which Work belongs to which occurrence.

#Reviewer and Review Report

A.13 first recovers ReviewService-4 as the exact actual performer through its obtaining review assignment, and A.15.1 independently admits ReviewWork-82. Because this example expressly distinguishes which assignment covered the review, F.6 afterward establishes that Work-assignment relation through the same assignment. F.6 identifies neither assignment nor performer, and failed attribution would leave the Work intact. ReviewReport-82 is a separately identified U.Episteme. When the Work first constitutes that episteme and the inception claim matters, A.15.PROD recovers one local entity-inception claim from the exact Work, change, and identity bases. The report can later participate in an evidence relation.

#Bias Annotation

#Working Guidance

1. State the assignment claim in ordinary language.
2. Select or admit the direct assignment species; do not start from a universal root signature.
3. Confirm the holder and exact local system-role-kind domain.
4. Declare every real additional participant and the species predicate; reject placeholder fields.
5. Decide whether a receiver needs explicit occurrence identity. Stop at the readable assertion when it does not.
6. Distinguish repeated episodes by uninterrupted predicate obtaining, not by storage identifiers.
7. Keep classification, capability, state, Method, Work, responsibility, commitment, permission, authority, access, evidence, reliance, and publication under their direct patterns.
8. Use context fields ending in ...SystemRoleAssignmentRef only with U.RelationRef constrained to U.SystemRoleAssignment and an exact recovered occurrence.
9. For source shorthand, recover each hidden value by kind and relation before relying on it.

#Conformance Checklist

#Common Anti-Patterns

#Consequences

#Rationale

The family is needed because system classification and assignment occurrence answer different questions. Direct species are needed because the participant law for a simple shift assignment differs from the law for an appointment tied to a real commission, position, or locus.

One root signature would either reject legitimate stronger assignments or hide them behind optional slots. A generic occurrence beside a stronger one would duplicate the world-side episode and make F.6 choose between competing identities. Subtyping the direct species under U.SystemRoleAssignment preserves one assignment identity and one common holder projection.

Predicate obtaining, assertion, explicit individuation, identifier assignment, evidence, and publication also answer different questions. Keeping them separate lets evidence be corrected without rewriting the occurrence and lets ordinary recognition text remain shorter than a full relation declaration.

#SoTA-Echoing

#Relations

Builds on: A.2 for system-role kinds and their exact local domains; A.6.REL for relation obtaining and occurrence identity; A.6.5 for complete SlotSpecs; and C.2.1 for assertions and interpretation epistemes.

Coordinates with: A.2.2 for capability; A.2.5 for assignment state; A.2.7 for relations among system-role kinds; A.3 and A.15 for Method and Work; A.15.1 and F.6 for performed-Work attribution.

Uses when current: A.1.1 for a selected model-use structure; C.27.TA when a positive temporal aspect is itself relied on; C.27 for temporal-claim adequacy; C.3.3, F.9, and A.6.9 for cross-context use; and direct responsibility, commitment, permission, authority, access, decision, evidence, reliance, provenance, currentness, and publication patterns.

Does not replace: a local system-role kind, a separate System-classification judgment, assignment state, capability, Method, Work, responsibility, commitment, permission, authority, access, 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 a system-role kind or assignment, MethodDescription, 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 system-role label or assignment becomes a hidden proof of ability, a MethodDescription is treated as if it can perform Work, a phrase such as “the system possesses algorithm A” is taken to admit an unspecified episteme as U.MethodDescription, 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 the exact system-role assignment, SystemRoleAssignmentStateRelation, Method-side admission conditions, and capability thresholds separately.

Not this pattern when.

• If the current claim is which admitted System is assigned to an exact local system-role kind, 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 local system-role kind, its classification, description, designation, exact assignment, relation structure, or bundle, use A.2, A.2.1, F.4, F.18, or A.2.7 for that exact object.
• 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 applicable characteristic or Scale pattern.
• 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

These ordinary sentences make different claims about welding:

• "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 state a local system-role assignment, MethodDescription, performed Work, or promise content. When FPF collapses them, project reasoning becomes brittle:

1. System-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 sufficient evidence of the holder's ability.
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.SystemRoleAssignment, 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, System, assignment, Method, and 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, local system-role kinds, system-role assignments, MethodDescriptions, 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 an admitted U.System: a physical, cyber, socio-technical, organizational, team, composite-cell, deployed-software, or other System satisfying A.1 for this claim.

WorkFamilyOrResultClassRef. The ability is about a class of work the holder system can perform or a result class it can produce. The envelope may cite the exact U.Method that prospective Work occurrences would enact, or a separately identified U.MethodDescription whose claims constrain the capability use. For a candidate episteme, apply A.3.2 before calling it a U.MethodDescription.

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.

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.

CurrentnessAssessmentRefs. A currentness assessment is a dated assessment relation saying whether the capability instance remains usable under its qualification window and current conditions. 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 local system-role-kind classification, exact assignment, Method step, WorkPlan, Work occurrence, ClaimScope, qualification window, or gate need. 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 forms (choose one for the current claim):

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

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

Either sentence form is a publication or statement about the capability instance.

#Separation From Neighboring Values

#Work-Admission Use

A Method step or Work claim may require both an exact system-role assignment and capability conditions.

WorkAdmissionCheck:
  systemRoleAssignmentCurrent: A.2.1 direct species under U.SystemRoleAssignment
  systemRoleAssignmentStateAdmitsWork: 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:

• one U.SystemRoleAssignment species defines the holder and assigned-kind participant meanings, the local system-role-kind domain, and any other participant meaning that changes the assignment predicate or occurrence identity; an occurrence supplies the holder System and other values for the case, and neither species nor occurrence establishes capability or Work;
• SystemRoleAssignmentStateRelation says whether that assignment satisfies the selected state predicate over the required window;
• one exact U.Method supplies the method-side condition, while an independently admitted U.MethodDescription or work-admission episteme may state the capability threshold used by the check;
• capability names the holder system's ability within the envelope, measure set, and window;
• capability-fit condition tests whether that instance meets the current threshold or gate need;
• after execution, A.13 first recovers the exact actual performer and A.15.1 independently admits the dated Work occurrence; F.6 performedUnderAssignment(W, RA) is added only when this capability account or its receiving use expressly consumes precise assignment-bound attribution through the same obtaining A.13 assignment, while actual enactsMethod(W, M) separately relates the Work to the exact Method;

Do not put the threshold into the local system-role-kind name. Do not treat a system-role classification or assignment as proof of ability or action. For performed Work, name the actual performer system. Do not treat a fit predicate, Q-Bundle, architecture-characteristic row, evidence relation, or currentness assessment as the capability instance. An algorithm-possession phrase is only a dispatch cue; it establishes neither dated performance nor U.MethodDescription membership.

#Worked Cases

#Manufacturing Cell

WeldingShiftAssignment is a declared species under U.SystemRoleAssignment. Under A.2.1 its signature defines the holder and assigned-kind participant meanings and uses WelderSystemRoleKindDomain as the local assigned-kind domain; it adds another participant only if that participant changes the assignment predicate or occurrence identity. One occurrence has RobotArm_A as holder, WelderSystemRole as the assigned-kind value admitted by that domain, and an extent lasting while the predicate obtains without interruption for the same participants. The assertion has exact claim content, EntityOfConcern, and effective ReferenceScheme; a ClaimScope, selected slice, interval, or qualification window is stated separately when it changes interpretation or validity. None of those values is another assignment participant. A separate Work or system-locus relation may place intended or performed welding at AssemblyLine_2026 when that relation obtains. The assignment proves neither permission, ability, action, nor performed Work.

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 an obtaining WeldingShiftAssignment whose local kind is WelderSystemRole and bead-width tolerance below 0.2 mm, the assignment and capability are both checked. The assignment does not supply the tolerance, and the capability does not assign the robot to the shift.

Shared boundary case — Robot-7 possesses an inspection algorithm. InspectionReleaseAssignment is a declared species under U.SystemRoleAssignment; under A.2.1 its signature defines the holder and assigned-kind participant meanings and uses InspectorSystemRoleKindDomain as the local assigned-kind domain. Occurrence InspectionAssignment-17 has Robot-7 as holder and InspectorSystemRole as the assigned-kind value admitted by that domain. This simple species declares no taxonomy, reference-scheme, generic-context, or interval participant. An assertion about the occurrence may cite MaintenanceRoles-2026, Maintenance-Scheme-A, and the candidate inspection interval as interpretation and description content.

Robot7-TurbineInspectionCapability-2026 is the separate holder-dependent capability instance for turbine-inspection Work within its declared sensor, calibration, input, measure, and qualification bounds. A statement that Robot-7 “possesses inspection algorithm A” does not by itself identify that capability instance, Method TurbineInspection@Maintenance-2026, a deployed-software relation, or a MethodDescription episteme.

Dispatch the phrase by claim: use A.2.2 only for the bounded ability; A.3.1 for the Method; a deployed-software or possession relation when that is the claim; and A.3.2 for candidate episteme TurbineInspectionProcedure-v3 only after its EntityOfConcern resolves to that Method and one substantive claim says how it is done.

Assignment and capability still do not prove execution. If InspectionWork-17 actually occurs, A.13 first recovers Robot-7 as the exact actual performer through obtaining InspectionAssignment-17, and A.15.1 independently admits the Work. Because this example expressly states assignment-bound attribution, F.6 afterward establishes performedUnderAssignment(InspectionWork-17, InspectionAssignment-17) through that same assignment; F.6 identifies neither assignment nor performer, and failed attribution leaves the Work intact. The Work occurrence separately stands in enactsMethod(InspectionWork-17, TurbineInspection@Maintenance-2026).

#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 their SystemRoleAssignmentStateRelation occurrences are neighboring claims. The capability instance keeps the department's ability visible and measurable; the management report describing it is an episteme 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 system-role assignment or its state relation changes, causing a Work-admission claim to fail even while 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 local system-role kind. A failed system-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. 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 system-role-kind names.
• Work records can be judged against the capability instance and fit predicate current at the time of work.
• The internal ability and measured envelope supporting a promise 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 system-role labels or assignments 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 lineage, not as the full current frontier. Current pressure comes from analyzable architecture, uncertainty-aware engineering, stakeholder-context formalization, and model integration. The NIST zero-trust line is used only for the split between current authorization and measured ability. SysML 2.0 is intentionally excluded as a SoTA authority or lineage for this decision: its model-element vocabulary does not settle the identity of capability holder, system-role kind, assignment, Method, Work, evidence, or capability occurrence, and no claim here depends on it.

#Relations

#Excluded Objects

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

• local system-role kind, direct system-role assignment, SystemRoleAssignmentStateRelation, structure of relations among system-role kinds, or system-role-kind 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. 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.

#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. For each PromiseContent episteme, the exact C.2.1 EntityOfConcern is the A.2.3:4.1.1 OutcomeSpec episteme designated 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, under which exact effective U.ReferenceScheme and U.ClaimScope, which exact local consumer system-role kind or other eligibility predicate applies, 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. Use U.Commitment only for an actual duty bearer after the applicable constitutive rule and its required instituting basis obtain.

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 explicit outcome and acceptance claims. Each neighboring claim keeps its named EntityOfConcern and direct relation, defined or tested by its own pattern.

Not this pattern when. If the current EntityOfConcern is an individual deontic relation, use A.2.8; if it is performed delivery Work, use A.15.1; if service or access wording hides its concrete subject or direct relation, start with A.6.P:4.11a. An exact bearer or access-providing arrangement is only one possible recovered reading; code or another episteme, Method, Work occurrence, participation, promise, permission, status, and direct relations keep their own readings. Use A.1 or A.1.SCR only when a separate repaired claim depends on that exact entity being a system. If source agreement or SLA wording combines several objects, use A.6.C to unpack them.

#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, use A.6.P:4.11a to recover whether it denotes code or another episteme, a Method, a Work occurrence or ordinary run, provider participation, an exact bearer or access-providing arrangement, permission, status, or a direct relation. A product label chooses none of these readings, and bare service has no default system reading. After recovery, name the referent or relation. Apply A.1 or A.1.SCR only when the recovered referent is an entity and the claim depends on its being a system.

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. It does not redefine a local system-role kind, system-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, or publication claim; use the patterns that define or constrain those claims. A.6.P:4.11a recovers which concrete service or access referent or relation the wording denotes; it does not replace the named participants and their direct relations with a locally minted service-situation relation. Use A.6.C to unpack agreement, SLA, or guarantee wording that combines unlike objects.

Plain reading. A promise content says what a consumer may rely on. A provider System can be classified under a local provider system-role kind. When a claim needs exact delivery Work, use A.13 to identify the System that actually did it. A.15.1 then admits the dated occurrence as Work from its Method, history, extent, and containing System, without relying on F.6. If the current use also needs to say exactly under which assignment that Work was performed, F.6 checks the separate relation against the same assignment used by A.13. A U.MethodDescription describes the Method.

PromiseContentUse obtains between the delivery-work occurrence and the selected promise-content edition during the named interval. Work-participation, affected-referent, change, delivery, and acceptance relations state what happened.

A separately performed evaluation applies the declared operation or method; its result binding states the evaluation value. If another use needs a verdict episteme, use C.2.1 to identify it and A.15.PROD to state any applicable entity-identity-inception claim. Evidence relations support the relied-on assertions.

Lexical note (L-SERV and A.6.P:4.11a). Bare service does not determine one FPF referent. When that word carries a relied-on claim, use A.6.P:4.11a to recover the concrete referent or relation: 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 recovery, name the referent or relation and use the pattern that defines or constrains the current claim. Resolve the defining or constraining ClaimGraph only when this claim or a named later use depends on a particular rule edition; the pattern id then serves as its locator.

#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 for that promise-content use; bare service does not identify a promise-content episteme.

Species-level identity follows C.2.1:

PromiseContentIdentity = <
  content,
  promisedOutcomeSpecRef,
  effectiveReferenceScheme
>

promisedOutcomeSpecRef is a U.EpistemeRef field that designates the exact A.2.3:4.1.1 OutcomeSpec episteme about which the promise claims are made; that episteme is the exact EntityOfConcern of this PromiseContent episteme. The field is not EntityOfConcernSlot: that SlotKind names the participant meaning only inside the reusable C.2.1 constitution RelationSignature. OutcomeSpec is a specification-use episteme form, not a separately admitted U-kind. The exact claimScope qualifies where the promise-content claims hold and remains outside the identity tuple.

• 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: The selected promise-content U.Episteme may participate in an exact EpistemePublicationRelation for a declared audience and bounded use. PublicationFormExpressionRelation relates that selected edition to its publication form, and PublicationFormBearingRelation relates a U.PresentationCarrier to the form it bears. Promise-content identity follows the C.2.1 episteme identity rule; no publication-relation occurrence, form, or carrier enters that rule.

#Promise-content schema

U.PromiseContent : U.Episteme {
  content                  : U.ClaimGraph,
  promisedOutcomeSpecRef   : U.EpistemeRef, resolving to OutcomeSpec,
  effectiveReferenceScheme: U.ReferenceScheme,
  providerSystemRoleKindRef : U.KindRef,
  consumerSystemRoleKindRef?: U.KindRef,
  claimScope               : U.ClaimScope,
  accessSpec?              : U.MethodDescription,
  acceptanceSpec           : U.Episteme,
  unitOfDelivery?          : U.Episteme
}

• 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.
• providerSystemRoleKindRef and consumerSystemRoleKindRef are promise-content fields typed by the existing U.KindRef; each resolves to one exact local system-role kind. 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 one of these content values or resolved kind references changes content and therefore the promise-content identity.
• promisedOutcomeSpecRef resolves to the A.2.3:4.1.1 OutcomeSpec episteme.
• effectiveReferenceScheme makes the claim graph and its references interpretable.
• providerSystemRoleKindRef and consumerSystemRoleKindRef identify local work-facing kinds; actual providers and consumers enter only through named occurrences of directly declared species under U.SystemRoleAssignment.
• claimScope is the exact U.ClaimScope over which the promise claims hold; it states the applicable operating conditions, populations, locales, and other admitted slices instead of leaving extent implicit.
• accessSpec describes the access method enacted when the admitted holder system of an eligible consumer system-role assignment requests access; an access-point system remains separate.
• acceptanceSpec states the acceptance criteria and selects the exact evaluation Method. It cites a MethodDescription edition only when the acceptance claim depends on that episteme's claims. Evidence-admissibility conditions may be stated there; actual evidence-use relations remain separate.
• unitOfDelivery states how accepted delivery work is counted when counting is current.
• There is no generic modelUseStructureRef field. When an independently selected BoundedModelUseStructure changes one actually model-local receiving interpretation, the receiving assertion or use designates that structure separately; the structure neither identifies the promise content nor becomes an optional participant of PromiseContentUse. A genuinely structure-dependent relation species would require its own direct pattern, mandatory structure participant, stronger predicate, and occurrence-identity rule.
• 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.

#OutcomeSpec - promised Work, post-work result, or both

This section is the authoritative FPF locus for the promise-facing OutcomeSpec shape. A.7 supplies the strict distinction among the specification episteme, Work occurrence, affected referent, post-work state, counting rule, and evidence; it does not define another schema.

promisedOutcomeSpecRef resolves to an independently identified specification-use episteme that says what is promised. OutcomeSpec is a specification-use episteme form, not a separately admitted U-kind.

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

  workSpec?: {
    methodConstraintRef?: U.MethodRef,            // resolves directly to an admitted U.Method
    methodDescriptionRef?: U.EpistemeRef,         // only when exact claims in one A.3.2-admitted edition are used
    workPredicateRef: U.EpistemeRef                // predicate on selected facts about delivery Work
  },

  resultSpec?: {
    entityOfConcernRef?: U.EntityRef,              // promised affected referent or its declared kind
    statePlaneRef?: StatePlaneRef,                 // where the post-condition is interpreted, when current
    postConditionRef: U.EpistemeRef                // predicate on the required post-work state
  }
}