SYSE.15:0.1 - Precision Restoration
| Name in this pattern | What it denotes |
|---|---|
| engineering Method | A reusable way of obtaining or preserving a named engineering result under stated participant meanings, conditions, applicability, and limits. |
| MethodDescription | An episteme about one identified Method that states a substantive way-of-doing claim. A standard, handbook, program, diagram, or workflow qualifies only when A.3.2 admits it. |
| recurring engineering result | A result needed in more than one relevant Work situation—for example, an operating-situation account, prediction, design choice, changed System, integration observation, configuration basis, assurance result, or release decision. The current claim must name its kind and use. |
| project conditions affecting Method choice | The actual System kind and use, or the intended System kind and use stated in the project-system choice account, operating environment, physical phenomena, configuration, evidence and authority needs, provider conditions, decision horizon, and losses that must be protected. These conditions form the comparison boundary. |
| Method-repertoire account | The episteme returned here: current Method choices, alternatives, exclusions, evidence, limits, supported relations, gaps, and reopen conditions for named project conditions. Use G.5 separately when a later selector needs a formal shortlist or joint-use set. |
| unresolved Method cue | A source phrase such as model-based process, AI workflow, agile, or systems approach whose reusable action, participant meanings, intended result, or boundary has not yet been recovered. |
| Method classification and specialization | A Method can meet several kind criteria and therefore have several broader Method kinds. This does not make the broader kinds parts, stages, or providers. |
| Method participation in whole Methods | One Method can contribute to several whole Methods. State each whole–part relation separately; shared participation does not identify the wholes with one another. |
| result use and dependency | A result from one Method can inform a decision involving another. That relation neither makes one Method part of the other nor proves a first–then Work order. |
| Work order and concurrency | Dated Work can overlap, recur, or follow a case-specific order while enacting the same or different Methods. A lifecycle diagram or table order does not establish that timing. |
| capability, assignment, provider, and platform | Different claims about which Agents can perform Work, who is assigned, how a result is obtained, and which supporting Systems are available. None follows from selecting a Method. |
| cultural prevalence | Claims about generation, transmission, recognition, selection, retention, or loss of Method variants in a population. One project choice establishes none of them. |
During this choice, each candidate Method is a project Method-of-interest because its identity, applicability, comparison, and retention are current project questions. That designation is project-relative, not a Method kind. After the choice, the Method’s enactment in engineering Work, any later Method-development Work, the Method-development Method, and the Agents and Systems involved retain separate relations.
Also keep the choosing Agent separate from performing Agents, and keep Methods separate from descriptions, tools, Work, results, authority, capabilities, provider arrangements, and the actual System or intended-system designator selected as the project system-of-interest.