| direct relation wording | A.6.P for recovery, then the rule that defines or tests the direct relation; use A.6.REL only when a receiving claim needs explicit occurrence identity or reference | RSIR stops when that direct rule is selected. An ordinary readable assertion may stop before explicit occurrence individuation or identifier assignment. |
| direct relation-participant meaning or actual participant | the direct relation pattern; add A.6.5 only if a receiving use needs a reusable typed declaration | State the participant meaning and actual participant directly. Neither one is a SlotKind, SlotSpec, designation, operation binding, or representation position. |
| reusable relation-declaration slot, field, parameter, argument, or endpoint | A.6.5 for one complete SlotSpec inside one exact RelationSignature, with A.6.0 for the containing signature | The SlotKind is declaration-local and corresponds to one already recovered participant meaning; the declaration does not make the relation obtain. |
| assertion- or description-side participant designation | C.2.1 for episteme identity and content; the direct assertion, evaluation, evidence-use, or description family for predicate, polarity, and use; A.6.5 only when a compatible current SlotSpec types the designation | An ordinary assertion may name actual participants directly. A typed designation remains episteme content: it is neither the actual participant nor evidence that the direct predicate obtains. |
| operation argument or result declaration | A.6.1 and the exact mechanism edition and operation declaration | ArgumentDeclaration and ResultDeclaration are declaration content. Do not reuse relation SlotSpec vocabulary for them. |
| exact operation application or declaration-local argument or result binding | A.6.1 and the exact mechanism edition and operation declaration | Identify the application occurrence independently; assert a binding only for the exact application and actual bound value under the declared predicate. Do not admit public OperationApplication, a universal input/output/result relation, or infer production, a produced entity, result episteme, evidence, or work from a result binding. |
| tuple component, formula or method-call argument, graph-edge endpoint, schema field, or other representation position | C.29 or the exact representation or publication pattern | Keep the position inside that representation and state explicit correspondence when an FPF claim consumes it; do not turn it into a relation participant, declaration, or actual binding by form. |
| signature or law-governed declaration | A.6.0; use A.6.5 only for SlotSpec declarations inside a RelationSignature, and A.6.1 for operation argument and result declarations | Do not put mechanisms, methods, work, evidence, actual participants, operation applications or bindings, or representation positions into signature identity-bearing content. |
| bare role already recovered as an exact local system-role kind — RSIR non-use | Apply E.10.ROLE once, then A.2, C.3, and the description or naming rules when their use is current | Do not apply RSIR. A system-role kind classifies entities already admitted as systems. It is not a SlotKind, assignment, capability, Method, status, or representation position. |
| bare role already recovered as a system-role assignment — RSIR non-use | Apply E.10.ROLE once, then A.2.1; when precise performed Work is claimed, recover each exact actual performer through A.13 and let A.15.1 independently admit the dated Work, adding F.6 only when the claim expressly consumes precise assignment-bound attribution through the same obtaining A.13 assignment; apply A.6.5 only for a reusable species declaration | Do not apply RSIR. Recover the assignment occurrence and its declared U.SystemRoleAssignment species. The species defines the participant meanings; the occurrence supplies the holder System, assigned local kind, and any other participants. Taxonomy and scheme epistemes are not generic participants. Assignment extent follows uninterrupted predicate truth; a receiving assertion or use names any interpretation edition it depends on. |
| state of an assignment to a system role, or structure of relations among system-role kinds | A.2.5, A.2.7 | Recover SystemRoleAssignmentStateRelation or SystemRoleKindRelationStructure; infer neither from ordinary label chains. |
| system-role-kind description or durable system-role-kind name | F.4, F.5, F.18, and F.17 when public or cross-context reuse is current | Name the exact local kind or its description episteme. Do not hide assignment, capability, Method, or Work inside the name. |
| independently encountered system-role enactment or assignment wording | When precise performed Work is current, apply A.13 first and let A.15.1 independently admit the dated Work; apply A.2.1 and F.6 afterward only when the claim expressly consumes precise assignment-bound attribution through the same obtaining A.13 assignment. If the starting cue was bare role, apply E.10.ROLE once and do not apply RSIR after it selects this branch | Recover the exact actual performer S : U.System and dated W : U.Work. For an attribution-bearing claim, also recover the exact obtaining RA : U.SystemRoleAssignment and use performedUnderAssignment(W, RA) or the Plain sentence S performed W under RA; F.6 identifies neither S nor RA, and missing or failed F.6 leaves W intact. Create no second enactment object beside Work and assignment. |
| module interface or architecture interface | A.6.M for module-interface claims; C.30, C.30.ASV, C.30.AD, or C.30.TFS-REL for architecture-of, structural-view, architecture-description, or transformation-flow-structure claims; A.6.0 plus A.6.5 only for a reusable RelationSignature and its complete SlotSpecs; C.29 or the exact representation pattern for interface diagrams or schema positions and their correspondence | Do not create generic U.Interface. |
| Markov blanket, Markov border, computational boundary, boundary leak, or active-inference boundary | Recover the current claim before choosing a pattern: accepted local Markov dynamics (A.3.3), mathematical or probabilistic lens (C.29, sometimes C.26), viability or measure-model-act envelope (C.26.3), holon delimitation or boundary crossing (A.1 plus the direct governing relation pattern), relation precision (A.6.P after a relation-bearing case is recovered), reusable RelationSignature and SlotSpec declaration (A.6.0, A.6.5) or representation position and correspondence (C.29 or the exact representation pattern), module-interface or interface-specification claim (A.6.M), functional port or functional element (A.6.F), physical component (A.14, C.13, B.3.5), boundary description or publication (C.2.1 for claim-bearing description content, C.30.AD for architecture descriptions, E.17 for reader-facing publication of an already accepted account), agency-threshold claim (A.13 for the agency criterion, C.16 when a value must be made interpretable as a measurement, A.19 when a declared CharacteristicSpace or reusable by-value CharacteristicSpacePredicate over it is the current object), or boundary-package statement classification (A.6.B) only when L, A, D, or E classification is the recovered object. | Do not create U.MarkovBlanket, generic U.Boundary, generic U.Interface, or binary U.Agent; do not treat a statistical separation, interface, interface module, physical component, description, and boundary-package classification as the same object. |
| functional port or functional structure | A.6.F, A.3.4, E.18, C.30.TFS-REL | Do not equate port, function, module interface, and signature by vocabulary alone. |
| API, protocol, connector, service-access wording | Recover the governed object first: E.17 for API or interface-description publication; A.6.0 and A.6.5 for a reusable RelationSignature and its SlotSpecs; C.29 or the pattern that defines the exact API-description claim for schema or representation positions and explicit correspondence; A.6.M for module-interface claims; A.6.C only when recovered protocol, service-term, SLA, or agreement-like wording bundles promise, utterance or publication, governance, Work or consequence, or evidence claims; A.6.P:4.11a when service or service-access wording still hides its exact referent or direct relation; A.6.B only for L, A, D, or E statement classification inside a boundary package. | API may be description, protocol episteme, exact service or access referent or direct relation, signature, publication, module interface, representation, or boundary-package statement classification. |
| capability | A.2.2; method, work, evaluation, or gate patterns only when they use an explicit capability criterion | Role labels and interface labels do not establish or demonstrate capability. |
| affordance or action invitation | A.6.A | Do not rename affordance as role, interface, or capability until its exact predicate and current subject assertion establish that value. |
| method, method description, work plan, or dated work | A.3.1, A.3.2, A.15, A.15.1, A.15.2 | Method, description, plan, and work are distinct even when source wording says process. |
| function or functional wording | A.6.F | Function-like wording can point to several patterns; A.6.F governs that recovery. |
| concern, interest, viewpoint, problem, or characteristic-space selection | A.7 for EntityOfConcern and description distinction; C.22 or C.22.2 for problem-card claims; E.17.0 or E.17.2 for viewpoint or view claims; F.4 or F.18 for system-role-kind-description or naming cases; A.19 or E.21 for characteristic-space cases | Do not mint generic U.Concern or U.Interest by wording alone. |
| publication, description, declarative representation, source wording | C.2.1, E.17, C.2.P.DR, E.10, E.10.ARCH | Do not let description or publication use displace the EntityOfConcern selected by the project concern. |