A.6.F:4.3 - Repair assignments
When a function-like phrase is claim-bearing, recover the exact object or claim under concern before lowering or rewriting the phrase. C.30.ASV does not define a world-side or view-local FunctionalElement individual. Its FunctionalStructureView is the same ArchitectureStructuralView episteme about one selected functional U.Structure; a FunctionalStructureViewUse may cite exact FunctionalElementClaim epistemes and other values needed by the use. Required or desired effects, actual transformations, candidate bearers, capabilities, ports, allocations, and correspondences remain separately established claims or values. If a distinct functional-element individual is genuinely needed, first define its predicate and identity in a subject pattern; otherwise stop at the smaller exact requirement, behavior or effect claim, capability, participant, condition, port declaration, or other directly defined object. A field name or source cue is not a substitute for that object.
Method-description guard. A procedure, code file, solver model, recipe, protocol, or algorithm is only a clue. First identify the knowledge object and the exact method it is about. Then point to at least one claim that says how that method is done, such as its transformation or enactment concern, applicability, precondition, intended effect or preserved condition, bound, generic participant meaning, or internal method composition. Only then classify that already identified U.Episteme as U.MethodDescription under A.3.2. A title, author, citation, approval, file form, or runnable artifact alone is a near-miss. If no admitted U.Method is its exact EntityOfConcern, or no way-of-doing claim is present, do not use U.MethodDescription: keep the actual plan, work, result, formal substrate, mechanism declaration, representation, publication occurrence or form, or carrier with its subject pattern. A different code, text, diagram, or publication form does not decide membership. If claim content, exact method, or effective reference scheme changes, C.2.1 first identifies the resulting episteme; then apply A.3.2 to that individual.
| Function wording use | Recovered object or claim and subject pattern | Boundary |
|---|---|---|
| required or desired functional behavior, transformation, or effect | Keep the requirement or other claim about the required or desired behavior or effect with its exact requirement, architecture, capability-gap, functional-view, method, or other claim-bearing pattern. Use U.Transformation only for one independently grounded actual bounded change under A.3.4. Use TransformationFlowStructure only for an independently selected structure over explicitly named loci, not for the required effect itself. | Requirement wording establishes neither an occurrence nor a filled FunctionalElementClaim. Stop at the claim pattern unless the changed referent, boundary, conditions, actual before/during/after facts, and continuity or reidentification rule are grounded. A functional view may cite the required claim, selected structure, bearer candidate, capability, and allocation without saying that the change occurred. |
| functional element in a view | Under C.30.ASV, use one ArchitectureStructuralView episteme whose EntityOfConcern is one selected functional U.Structure. When needed, add a FunctionalStructureViewUse that cites exact C.2.1 FunctionalElementClaim epistemes and only separately established behavior or effect, bearer, capability, port, allocation, or correspondence values. | This is a claim-and-view interface, not a FunctionalElement individual, loose table row, or module. If no bearer or candidate allocation is current, keep the requirement, required-behavior claim, required-effect claim, capability gap, functional-behavior slot, or candidate-allocation question with its subject pattern. |
| transformer-side filler and candidate bearer | For a design-only candidate, keep the candidate transformer-side system locus or candidate U.System reference without asserting an assignment or performed Work. If the local kind TransformerSystemRole is current, name that kind; add a separate judgment classifying a System under it only when that judgment obtains. If an assignment is independently current, recover its directly declared species and its obtaining occurrence with actual participant values, holder, applicability, and extent under A.2.1. If performed Work is independently current, point to its basis: A.13 first, independent A.15.1 Work admission second, and F.6 afterward only for precise assignment-bound attribution. Coordinate the selected locus with A.3.4 TransformerRef?, A.7, A.15, A.15.1, and A.15.2 only for the claims that are actually current. | A FunctionalElementClaim may cite an independently established candidate-bearer locus, but that citation is not the whole transformer ontology. A kind, classification judgment, assignment species, assignment occurrence, and dated Work are independent facts; none manufactures another. |
| input condition, output condition, and functional ports | A.3.4 InputConditionRefs?, OutputConditionRefs?, and FunctionalPortRefs?; U.Signature discipline through A.6.0 and A.6.5 when accepted or produced states, media, flows, signals, information, work products, formal objects, or functional port signatures matter | A functional port is not automatically a module interface. Use A.6.M only when module-interface or substitution compatibility is the claim. |
| capability of a holon | the qualified ability claim about an identified System under A.2.2 | Does not imply that a method, module, work occurrence, or successful transformation exists. |
| method or algorithm wording | U.Method only when the claim concerns a reusable semantic way of doing; U.MethodDescription only for an already identified U.Episteme that passes the A.3.2 guard above: one admitted U.Method is its exact EntityOfConcern and at least one claim says how that method is done | Procedure, code, solver, recipe, protocol, and algorithm forms are clues only; they establish neither membership, execution, nor evidence. |
| mechanism wording | U.Mechanism through A.6.1 and E.20 when a law-governed realization or operation structure is the claim | Does not become a method, Work occurrence, capability, selected functional structure, or functional-view claim by label. |
| work plan, work occurrence, or work result | Recover the exact U.WorkPlan under A.15.2, one exact dated W : U.Work under A.15.1, or the separately identified result entity or episteme together with the predicate that relates it to the current Work or application. Use A.15.PROD when production, entity inception, or production completion is current, and A.6.RCD only when the needed direct result relation has no current governor. | A plan, Work occurrence, and result are different objects. None implies reusable function ontology or completed functioning, and a result is not part of Work identity. |
| system-role or responsibility wording | VP.AllocationResponsibility is only a recognition cue. A positive responsibility claim names an admitted domain responsibility predicate, its actual participants, applicability, and occurrence identity; otherwise return the exact A.6.RCD missing governor. If an assignment claim is also current, recover its directly declared species and obtaining occurrence under A.2.1. If performed Work is current, point to its basis: A.13 first, independent A.15.1 Work admission second, and F.6 afterward only for precise assignment-bound attribution. | A system-role kind, classification judgment, assignment, function phrase, commitment, position, authority label, or Work attribution establishes no responsibility relation by form. Responsibility may obtain with or without a commitment, and each relation keeps its own predicate and identity. |
| participation or actual functioning | Name the direct domain predicate, actual participants, applicability, and occurrence identity for the claimed participation or functioning. If the corpus has no such predicate for the receiving use, return the exact A.6.RCD missing governor. | Assignment, capability, allocation, nearby Work, or a function label does not make participation or actual functioning obtain. |
| mathematical function or relation | C.29 mathematical-lens use with domain, codomain or relation domain, preserved and lost structure, lens-use admissibility value, and stop condition | Does not become architecture, evidence, causal proof, assurance, or decision claim by itself. |
| quality or fitness expression | C.25, C.16, C.16.Q, A.17, A.18, or an admitted characteristic or measurement subject pattern according to the claim being made | Does not let “functionality” carry a quality claim without bearer and subject pattern. |
| module allocation | Recover the exact allocation or correspondence claim or relation under its subject pattern. When a functional view cites it, use FunctionalStructureViewUse with its ArchitectureStructuralView and the exact claim or relation reference; use A.6.M when a module-interface claim is being made. | Does not make function and module one FPF kind. One selected functional structure may have allocation claims involving several modules, one module may occur in claims about several functional structures, and a module may have no current functional-view claim. |
| interface relation, module-interface relation, or signature relation | Use A.6.RSIR first when bare interface, API, port, protocol, or service-access wording could point to several direct EoCs; then use A.6.M for the module-interface boundary and A.6.0 and A.6.5 for signature discipline, with A.6.B, A.6.C, or A.6.P:4.11a only when that boundary, interface condition, API, protocol, service, promise, or duty claim is being made | Does not turn a functional link, port label, API name, or signature into implemented compatibility. |
| evidence, result, assurance, gate, decision, or publication claim | the direct evidence, result, assurance, gate, decision, publication, or source pattern named by value | Function wording can point to these claims, but it does not authorize or prove them by itself. |
| functional architecture | ArchitectureOf@Context whose structureKindRefs includes FunctionalStructure, one selected functional U.Structure, and the ArchitectureStructuralView episteme about that structure. Use FunctionalStructureViewUse only when citations to exact FunctionalElementClaim epistemes or other separately established values change action. | Not a peer architecture ontology, functional-element individual, selected transformation-flow structure, or mathematical graph description by itself. |
Required-versus-actual check. “The cooling loop shall reduce outlet temperature by 8 °C within 60 seconds” remains a requirement or functional-view claim; by itself it identifies no U.Transformation. If a later run actually changes the loop state, identify that cooling occurrence separately under A.3.4 from the changed loop, exact boundary and conditions, actual before/during/after facts, and continuity or reidentification rule. Requirement-only material is the countercase and stop: it cannot admit an actual transformation, observed functioning, or evidence of success.