E.17.2:4.3 - Keep the four concern conventions distinct
Functional. A conforming candidate episteme foregrounds exact transformations, capabilities, effects, functional elements, or transformation-flow relations of its holon. It does not identify a module structure by functional vocabulary and does not mint U.Function. Any neighboring responsibility claim keeps the admitted System, local system-role kind, current C.3.2 classification judgment, exact assignment, kind-relation structure, capability, transformation, and direct responsibility relation separate; use A.2, C.3.2, A.2.1, A.2.7, or the direct responsibility pattern for the claim actually made.
Procedural. A conforming candidate episteme foregrounds exact methods, order, state, concurrency, failure, and recovery related to its holon and designates the exact admitted method, state-transition, or transformation-flow relations on which each claim depends. A procedural view about a holon is not a U.MethodDescription; that dependent kind requires one admitted method as its exact EntityOfConcern. Ordinary operational recovery needs no safety package unless the claim is safety-bearing or a named receiving decision relies on one.
Allocation-responsibility. A conforming candidate episteme foregrounds exact Systems, local system-role kinds, current C.3.2 classification judgments, obtaining assignments, relations among those kinds, capabilities, transformations, and separately governed responsibility relations or selected structures related to its holon. A label creates no kind, classification, or assignment; a classification judgment needs its candidate, kind, KindSignature edition, and context slice but no assignment. The view may state that judgment, but it does not make the criterion true or create an assignment or responsibility relation.
Module-interface. A conforming candidate episteme foregrounds exact constituent holons, dependency structures, boundaries, interfaces, compatibility, substitutability, and change policy. It remains distinct from the functional viewpoint: many modules may support one transformation, one module may support several transformations, and either description may be incomplete without becoming the other.
The following are practitioner recognition and claim-shape cues, not embedded StakeholderFamilies or AllowedEpistemeKinds fields. A reader label creates neither a system-role classification nor an assignment and enters neither viewpoint nor view identity; every example still needs its exact EntityOfConcern, the predicate and participants of each claimed relation, its obtaining test, and its E.17.0 conformance result.
| Template position | Typical readers or concern holders | Distinctive claim-shape and conformance cues |
|---|---|---|
| functional | System-engineering and architecture readers, product or capability owners, and reliability or performance readers inspecting capability envelopes | Look for service-capability and promise content, delivery or access and API descriptions, input/output signatures, and functional-port boundaries as separate claims about the holon. Ground bounded behavior in exact transformations, capabilities, or a selected transformation-flow structure; keep service delivery Work, access relations, publications, and module interfaces separate, and do not mint U.Function. |
| procedural | Operations and run-time owners, control and automation engineers, and safety readers | Look for exact operational subjects and admitted method, state-transition, and transformation-flow relations behind order, state, concurrency, failure, and recovery claims. Where step boundaries are current, make preconditions and postconditions explicit and type-checked. Open an exact safety-analysis basis or A.10 evidence path only when the current claim is safety-bearing or a named receiving decision relies on it; otherwise stop at the operational relations and ordinary failure/recovery boundary. Within that triggered branch, use B.3 only when an actual named assurance claim for that use is current. Keep method, method description, work plan, dated Work, calendars, and selected state or flow structures distinct. |
| allocation-responsibility | Organization and operations designers, safety or compliance readers concerned with segregation of duties, and device or system engineers | Look for the admitted System and exact local system-role kind; when the claim says that System counts under the kind, recover the separate four-input C.3.2 judgment. Look separately for any assignment occurrence, segregation and escalation constraints, capability and transformation claims, and responsibility relation or structure. A kind locator is neither a classification result nor an assignment; none of those claims proves responsibility; allocation wording is not an obtaining relation. |
| module-interface | Hardware or software architects, integration and test engineers, and lifecycle or maintenance readers concerned with replaceable units | Look for module decomposition, protocols, schemas, physical connectors, APIs, interface and conformance expectations, version and change policies, dependency and allowed-coupling structures, replaceability and variation points, and explicit functional-to-module correspondence or allocation without identity by default. Ports or connector diagrams do not establish module/interface relations; state and test each direct relation separately, and use A.6.4 for any functional-to-module retargeting. |