ME.10:4 - Solution

Build a bounded set of named-user task criteria, compare candidate configurations against that same set, test the retained route or routes, and repair the first defeated material, relation, condition, or task. Return several candidates, a stated split boundary, or a missing priority or test whenever the current basis does not justify one winner.

Use a cheap ordinary task-and-gap row for a small reversible case. When success depends on a Work or WorkPlan performer-support configuration, interruption, handoff, stale state, support loss, or recovery, apply the current A.15.8 branch and probe rather than redefining it here. When several criteria, missing evidence, or incomparability make the configuration choice non-trivial, consume current A.19.CPM comparison results and A.19.SelectorMechanism selected-set semantics rather than forcing one route. ME.10 specializes these patterns for Method material through two content branches.

In the direct branch, take the C.37 direct exit when one owning result already supplies the complete one-result/one-use selection and limits. When the ME.10 task row owns that use, keep the same logical basis: receiver/action, direct result, exact claim, applicable reliance, receiving task result, exposure and loss, disposition and return. Retain it in that row only when later use needs it; a sufficient immediate answer needs no new C.37 record or ME.9 profile.

In the profile branch, consume one complete ME.9 profile when complementary governed representations must be allocated to unlike named Method-related actions. That profile contains one complete C.37 claim group per action and a separate Method-specific result showing the shared source, correspondences, conflicting omissions, edition relations, decisions to keep representations separate, and conditions that require reconsidering several selections.

Both branches preserve Method and candidate status, the ME.8 source account, Method Base collection and edition facts, retrieval and tailoring particulars, provider and AI boundaries, named-use task rows, and their return paths. Neither a C.37 row nor the ME.9 cross-use result selects the support configuration.

If the task set, comparison basis, or observable test cannot be recovered, return missing-task-set, missing-configuration-basis, or missing-task-test. If retained candidates require an absent priority or decision, return unresolved-configuration-choice[...]; do not improvise a platform or call a local minimum the arrangement.

ME.10:4.1 - Pattern-Use Unfolding

1. 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.

2. 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.

3. 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.

4. Construct candidates against the same task set. Compare at least two materially different routes, or state why no smaller route could meet the rows. For every candidate, 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.

5. 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.

6. Compare and retain without forcing a winner. A small reversible case may use an ordinary comparison row when 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. Otherwise retain the alternatives and missing priority or evidence, or split the arrangement by a stated task, user, confidentiality, authority, or maintenance boundary.

7. 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.

8. 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.

9. 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.

10. 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.

11. 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.

12. 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.

13. 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.

ME.10:4.2 - Record the Result

ME.10:4.3 - What Changes in Practice

Teams stop measuring progress by uploaded files, platform features, or one locally successful task. They can show which named uses a configuration covers, which are untested or incompatible, why one route is supported or several remain, and which edition, relation, condition, permission, authority, capability input, or Work result must change.

The same discipline makes automation safer. A user System or provider may be human or non-human and may retrieve, compare, or propose; performed Work, consumed output, permission, authority, capability, evidence status, and result remain visible and separately testable.