ME.10:4.1 - Pattern-Use Unfolding

Construct the bounded task set. For each named user System and use, name the actual Method, candidate account, description, representation, aid, or other support result to be retrieved or used; the receiving Work or decision; the use relation; and the Work task. Mark each criterion mandatory or optional for this configuration decision and state pass, failure, qualification window, and stop observations. A user System may be human, automated, biological, organizational, computational, or mixed.
Select only the needed Method content and branch by use. Identify the admitted Method or status-preserved candidate account and its current ME.8 MethodDescription or candidate-account edition.

Direct branch: use the owning complete one-result/one-use answer and its material limits. When the ME.10 task row owns the use, retain the applicable complete C.37 basis there if later use needs reconstruction; otherwise finish the sufficient immediate answer. Do not create an ME.9 row or duplicate standalone account, or report their absence as a gap.

Profile branch: when complementary governed representations serve unlike named actions, consume one complete ME.9 profile. Require one complete C.37-bearing row for every action, then require the separate cross-use result that returns all rows to the same Method source and records correspondences, conflicting omissions, edition relations, keep-separate decisions, and changes that reopen several rows. If the source account, a direct result, reliance or receiving layer, one action row, or the cross-use result is missing, stale, or for another action set, return that exact gap instead of importing colocated artifacts as a profile.
Identify the participating Systems and current relations. Keep the project, users, provider, repository, tools, and automation as independently identified Systems where applicable. State actual access or provision, assignment, permission, authority, capability, publication, and direct System-use relations separately; return a missing relation rather than inferring it from configuration.
Assess the available route and compare for a live choice. For a small reversible task, keep an available configuration when the task evidence supports every mandatory criterion, no stop is violated, and its burden is acceptable for this use. This sufficient result needs neither a second route nor a proof that no smaller route exists. Open comparison when a failed criterion, material burden, changed task, or plausible alternative could change the configuration decision enough to justify the comparison’s cost. For every candidate actually considered, map every mandatory and optional task criterion, stop, burden, risk, and required relation. Include cross-task effects such as shared currentness, duplicated maintenance, conflicting confidentiality, latency, provider exposure, or incompatible authority. A per-task minimum does not automatically make their union a smallest shared configuration.
Keep evidence status distinct. For each candidate-and-criterion cell record ordinary evidence status: observed pass, observed failure, untested, insufficient because a declared feature or relation is absent, or unknown because information is missing. These phrases are task-account content, not new FPF kinds. Do not convert untested into insufficient, or a pass by one route into failure by another.
Resolve the live choice without forcing a winner. When step 4 already establishes an adequate route for the bounded task, retain that result without claiming that it is the smallest or best route. When comparison is needed, a small reversible case may use an ordinary comparison row if explicit yes/no coverage and burden make the order clear. When comparison is multi-criteria, partial, evidence-gated, or otherwise non-trivial, use A.19.CPM and, when selection is required, A.19.SelectorMechanism; preserve incomparability, degrade, abstain, and a selected set. Claim one smallest sufficient route only when it covers every mandatory criterion, violates no stop, and the declared comparison and selection basis supports a singleton. If that comparative claim remains unsupported, retain the alternatives and missing priority or evidence, or split the arrangement by a stated task, user, confidentiality, authority, or maintenance boundary.
Configure only a justified test route or retained set. Set the retrieval and selection aids, status and provenance cues, tailoring rules, tool or automation behavior, provider boundary, decision boundary, feedback receiving use, and stop conditions supported for the declared tasks. Choosing a candidate for bounded testing is not an A.22 structure selection and does not erase other retained candidates.
Add a curated Method Base only when needed. Identify the project or namespace, collection purpose, current entry-disposition rule, admitted entry kinds, return conditions, edition policy, and continuity. Institute membership only through the identified granted-permission occurrence, admitted Work, operation application, result binding, and direct belongs-to predicate required by the local declaration. A label, folder, record, result token, or publication occurrence creates no membership.
Select an A.22 structure only when organization changes the action. Identify independently admitted constituents, the identified obtaining relation occurrences selected, applied constraints, and named use frame. Then identify the selecting System, Method, dated selection Work, and direct participation or operation-binding facts. If those neighboring facts are missing, keep the proposed organization and return missing-selection-basis.
Keep editions and reliance accounts separate. Maintain a C.2.1 episteme about the Method Base edition and, when a receiving decision needs it, a separate named-use episteme that states the identified Systems, Work, capabilities, and direct relations relied on. Use C.13 only when a materialized construction account changes the receiving use. Publication and actual access remain separate results.
Choose and run task probes. Cover every materially different mandatory task family with a representative row or state why one observed row covers several; add at least one discriminating condition for each live weakness that can change the configuration decision. For a simple case, admit and observe each actual task Work directly. When configuration or recovery under interruption, handoff, changed performer, stale state, or support loss matters, apply one A.15.8 actual-Work or present-WorkPlan branch at a time and use its weakest decision-changing probe. Admit performed probe Work separately. Do not call convenience statistically representative or merge several Work foci into one.
Repair, recompare, and rerun only the affected position. Change the material, System, relation, constraint, access condition, assignment, permission, authority, capability input, edition fact, provider boundary, feedback path, or user step that defeated a criterion. Preserve unaffected collection, proposal, candidate, and task facts. Rerun the same criterion. If the bounded task set, candidate universe, criteria, scope, evidence status, or window changes, make a new comparison or selection use rather than reusing the prior minimum.
Return the bounded result and next use. Report per-task evidence status, supported configuration, retained candidate set, split boundary, failed task, changed position, rerun result, or named missing premise. State whether it can feed a representative Method trial, a description or representation correction, a collection repair, another user-task repair, or later capability development. Reopen only the affected row, configuration comparison, or directly governed result.