A.6.1:1 - Problem frame

An engineer needs a reusable declaration of operations, their typed argument and result positions, the laws they preserve, and the conditions under which an operation is admitted. The declared operation family may be used for physical modeling, clinical calculation, selection, normalization, or another named engineering use.

Use this pattern when the working question is:

What operation family is being declared, which laws govern it, and under which claim scope, time, selected CHR:ReferencePlane, and mechanism conditions may its operations be used?

Primary governed object. One claim-bearing episteme being identified as U.Mechanism. Inside that episteme’s C.2.1 identity, its exact EntityOfConcernRef identifies the declared operation family. U.Mechanism is a dependent durable U-kind governed through the U.Signature identity and content settlement; it adds operation and admission semantics to the reusable declaration. The episteme and the declared operation family remain distinct: the episteme carries the declaration, while EntityOfConcernRef identifies the family.

Primary working reader and concern. The reader is an engineer who needs to reuse or compare an operation declaration without confusing it with the method that uses it, the entity that realizes it, the work that evaluates it, or a publication that presents it.

The first useful move is to name the declared operation family, its SubjectKind, and its family-level RangedValueKind, then state its OperationAlgebra, LawSet, AdmissibilityConditions, and exact Applicability. Add a family-level ResultKind only when one distinct result kind is current. For each reused operation, point to the argument or result meaning that carries the SubjectKind, RangedValueKind, or ResultKind meaning, then declare every additional argument and result meaning and exact ValueKind. Also state the operation’s ApplicationPredicate, ApplicationExtentRule, and ApplicationIdentityRule. ApplicationExtentRule maps the facts at one independently grounded application locus to the semantically relevant boundary or interval over which that operation’s predicate obtains; it is not the signature-level ExtentRule that determines kind membership at a selected context slice. Open an actual operation-application binding only when one particular application has been independently identified and a downstream claim says which value that application used or returned. Add a dependency manifest only when removing one named provider term or law would make this declaration uninterpretable or prevent law replay; shared wording or a background citation is not a dependency.

What goes wrong if this pattern is missed: implementation behavior, method instructions, evaluation outcomes, and publication metadata enter the declaration as if they were operation laws. A later user cannot tell whether the declaration changed, one realization failed, or only the evidence became stale.

What this buys: the declaration can remain stable while methods, realizers, evaluations, descriptions, and publications evolve under their own patterns.

Do not use this pattern merely because prose contains words such as mechanism, algorithm, process, or workflow. Recover the current object first. Use A.3.1 when the current object is a semantic way of doing, A.15.1 when it is performed work, and the direct system or episteme pattern when it is a physical assembly or a model description.