#U.MethodDescription: The Recipe for Action

Pattern A.3.2 · Stable Part A - Kernel Architecture Cluster

Projects need a stable way to express “how it is written”—the recipe, code, SOP, rule set, or formal proof—without confusing it with:

#Aliases

• U.MethodDescription

#Keywords

• specification
• recipe
• SOP
• code
• model
• epistemic artifact.

#Relations

#Content

#Context (plain‑language motivation)

Projects need a stable way to express “how it is written”—the recipe, code, SOP, rule set, or formal proof—without confusing it with:

• the semantic “way of doing” (that is U.Method),
• the assignment (that is U.RoleAssignment),
• the ability (that is U.Capability),
• the execution (that is U.Work), or
• the calendar plan (that is U.WorkPlan).

U.MethodDescription gives this anchor. It treats algorithms, programs, proofs, SOPs, BPMN diagrams, solver models, playbooks as one class of epistemes: knowledge on a carrier that describes a Method. This unifies software and “paper” procedures and lets teams switch notations without breaking the model.

#Problem (what breaks without a clear MethodDescription)

1. Spec/run conflation. A flowchart or code is mistaken for the run; audits and SLOs become unreliable.
2. Who/time leakage. People and calendars creep into the recipe; reuse and staffing agility die.
3. Step‑only bias. Functional or logical styles are treated as “not real methods”; designs get contorted into faux steps.
4. Algorithm‑centrism. Only code is considered “the method”, leaving SOPs and scientific procedures second‑class.
5. Structure entanglement. BoM/PBS elements end up inside the recipe; method and product structure tangle.
6. Unstated equivalence. Two specs intended to mean “the same method” are not declared equivalent; teams fork semantics by accident.

#Forces (what we must balance)

#Solution — the specification as an episteme describing a Method

#Definition

U.MethodDescription is an U.Episteme that describes a U.Method in a concrete representation (text, code, diagram, model). It is knowledge on a carrier that can be reviewed and validated; at run-time a U.System uses it to execute the U.Method as U.Work under a U.RoleAssignment.

Strict Distinction (memory aid): Method = how in principle (semantic Standard). MethodDescription = how it is written (artifact/description). Work = how it went this time (dated execution).

#Representation‑agnostic stance (independent of “algorithmic paradigm”)

U.MethodDescription does not privilege any single notation. Typical forms include (non‑exhaustive):

• Imperative Spec — SOP, BPMN/flowchart, PLC ladder, shell/pipeline scripts.
• Functional Spec — compositions of pure functions, typed pipelines, category‑style combinators.
• Logical/Constraint Spec — rules/goal sets, SAT/SMT/MILP models, theorem‑prover scripts.
• Statistical/ML Spec — model definitions, training/evaluation procedures, inference pipelines.
• Reactive/Event‑driven Spec — statecharts, observers/triggers, stream/CEP rules.
• Hybrid Spec — mixtures (e.g., imperative orchestration calling solver kernels).

Same Method, different MethodDescriptions. In a single U.BoundedContext, several MethodDescriptions may describe the same U.Method if they entail the same preconditions, guarantee the same effects, and meet the same non‑functional bounds (cf. A.3.1).

#What a good MethodDescription states (paradigm‑neutral content)

Not a schema—these are content prompts for reviewers:

1. Purpose & Name of the Method it describes (link to U.Method).
2. Interface/ports (inputs/outputs/resources/Standards) in the context’s vocabulary.
3. Preconditions (guards, invariants, required states).
4. Postconditions / Effects (what is guaranteed upon success).
5. Non‑functional constraints (latency, precision, cost, safety envelope).
6. Role requirements for enactment (kinds, not people)—to be satisfied at run time via U.RoleAssignment.
7. Capability thresholds the performer must meet (checked against U.Capability of the holder).
8. Failure semantics (detectable failures, compensations, rollback/forward strategies).
9. Compositional hooks (how this spec composes: serial/parallel/choice/iteration), without embedding calendars.
10. Parameter declarations (what may vary per run; values bound at U.Work creation).

Didactic guardrail: A MethodDescription does not embed a schedule, assignees, or BoM. Calendars → U.WorkPlan; people/units → U.RoleAssignment; product structure → PBS/SBS.

#Epistemic roles for MethodDescriptions (via U.RoleAssignment)

Being an Episteme, a MethodDescription may itself play epistemic roles via U.RoleAssignment in a context (classification, not action), e.g.:

• ApprovedProcedureRole, RegulatedProcedureRole, SafetyCriticalProcedureRole, De‑factoStandardRole.
• These do not make the spec an actor; they classify its status within the context (who may use it, in which settings).

#Constructor‑theoretic note (unifying “algorithms” and “physical recipes”)

In the constructor‑theoretic reading used by FPF:

• Algorithms, programs, solver models, proofs are all U.MethodDescription—descriptions of Methods that transform information.
• SOPs, control recipes, lab protocols are U.MethodDescription—descriptions of Methods that transform matter/energy.
• A universal transformer (a system with sufficient capability) enacts any physically admissible MethodDescription—not only informational ones.

This keeps software and “wet lab” on equal footing.

#Clear distinctions (quick litmus for managers)

#Archetypal grounding (parallel cases)

#Industrial SOP (imperative)

• Method: Etch_Al2O3.
• MethodDescription: SOP_Etch_v7.pdf + PLC ladder file.
• Role requirements: EtchOperatorRole; Capability: gas‑control precision ≤ threshold.
• Execution: Tool_42#TransformerRole:Fab_A enacts the spec → Work runs W‑143…W‑155.

#Optimization model (logical/constraint)

• Method: JS_Schedule_v4.
• MethodDescription: MILP model + solver config; admissible solution definition.
• Execution: PlannerService_v4#TransformerRole:Plant_2025 produces Work Run_2025‑W32‑P1.

#Clinical guideline (epistemic, status via RoleStateGraph + State Assertion)

• Method: AcuteAppendicitis_Triage.
• MethodDescription: clinical decision rule set; Epistemic Role: RegulatedProcedureRole:Hospital_Context.
• Execution: ER_Team#TransformerRole:ER_Shift enacts the spec on a case → Work visit V‑8842.

#Bias‑Annotation (as in E‑cluster)

• Lenses tested: Did, Prag, Arch, Epist.
• Scope declaration: Universal; semantics are context‑local via U.BoundedContext.
• Rationale: Elevates all procedural artifacts—code, SOPs, proofs, models—to a single class, avoiding algorithm‑centrism and step‑only bias. Keeps the strict split among Method / MethodDescription / Work / Role / Capability.

#Conformance Checklist (normative)

CC‑A3.2‑1 (Episteme status). U.MethodDescription IS an U.Episteme (knowledge on a carrier). It is not a U.Method (semantic way), not a U.Work (execution), not a U.Role/RoleAssigning (assignment), not a U.WorkPlan (schedule), and not PBS/SBS content.

CC‑A3.2‑2 (Context anchoring). Every U.MethodDescription MUST be interpreted within a U.BoundedContext. Names, Standards, and admissible non‑functional bounds are local to that context.

CC‑A3.2‑3 (Method linkage). A U.MethodDescription MUST declare the U.Method it describes. Multiple MethodDescriptions MAY describe the same Method (see CC‑A3.2‑8).

CC‑A3.2‑4 (assignment/time‑free). A MethodDescription SHALL NOT embed assignees, org units, or calendars. People/units are bound via U.RoleAssignment at run time; calendars belong to U.WorkPlan.

CC‑A3.2‑5 (Structure‑free). BoM/PBS/SBS artifacts SHALL NOT be embedded in MethodDescriptions. Reference interfaces/resources and constraints instead of listing parts/assemblies.

CC‑A3.2‑6 (Role and capability requirements). A MethodDescription MAY state role kinds and capability thresholds required for enactment. These are requirements, not bindings. They are checked at run time against U.RoleAssignment and U.Capability.

CC‑A3.2‑7 (Parameterization). Parameters MUST be declared in the Method/MethodDescription; concrete values are bound when creating U.Work. Default values in a spec are allowed but SHALL NOT force a schedule or assignee.

CC‑A3.2‑8 (Semantic equivalence). Two MethodDescriptions describe the same U.Method in a given context iff they entail the same preconditions, guarantee the same postconditions/effects, and satisfy the same non‑functional bounds for all admissible inputs/conditions of that context (per A.3.1 CC‑A3.1‑7). Differences in control flow, search, or notation do not break equivalence.

CC‑A3.2‑9 (Refinement). Spec₂ refines Spec₁ for the same Method iff it preserves interface, does not weaken postconditions/effects, and tightens (or equal) non‑functional bounds under equal or stronger preconditions. Declare refinement explicitly in the context.

CC‑A3.2‑10 (Compatibility claims). Claims such as “sound but incomplete” or “complete but potentially unsound” relative to another MethodDescription MUST be stated explicitly and scoped to the context (e.g., solver approximations).

CC‑A3.2‑11 (Executable specs). Executability does not change status: an executable artifact (program, script) is still a MethodDescription. Its runs are Work; its semantics are the Method it denotes.

CC‑A3.2‑12 (Epistemic roles via U.RoleAssignment). A MethodDescription MAY play epistemic roles via U.RoleAssignment (e.g., ApprovedProcedureRole, RegulatedProcedureRole) that classify its status. Such bindings do not make the spec an actor.

CC‑A3.2‑13 (Non‑determinism declaration). If a MethodDescription permits non‑determinism (e.g., search/optimization), the space of admissible outcomes and acceptance criteria MUST be stated (so that Work can be judged).

CC‑A3.2‑14 (Bridging across contexts). If two contexts use different MethodDescriptions for “the same‑named way,” an explicit Bridge (U.Alignment) SHOULD be provided to map terms/assumptions. Do not assume cross‑context identity by name alone.

#MethodDescription mereology (epistemic composition; not method composition)

Keep two worlds separate:

• Method composition (design‑time semantic): combines Methods into new Methods (A.3.1 §9).
• MethodDescription mereology (epistemic): combines documents/code/models into larger spec artifacts. This is about parts of the description, not about the semantic method algebra.

Epistemic part relations (illustrative):

• ConstituentOf — a chapter/module/snippet is a constituent of a larger spec.
• Imports/Uses — this spec reuses a library/rule set.
• VariantOf — this spec is a variant (e.g., for different equipment) with declared deltas.
• RepresentationOf — this visual diagram is a representation of the textual rule set.

Didactic rule: Do not infer that a spec with two modules means a Method with “two steps.” Modules are parts of the description, not necessarily steps of the Method.

#Parameterization & variability (templates, defaults, configs)

Templates. A MethodDescription may serve as a template with parameters (e.g., temperature set‑points, solver tolerances, objective weights).

Binding time.

• Declare parameters in the spec;
• Bind values when creating U.Work (or at an agreed “compile” stage);
• Keep bound values visible in the Work record (so runs can be compared).

Defaults and guards.

• Defaults are allowed; list valid ranges and guards (e.g., safety constraints).
• If a default has safety impact, state it explicitly as part of preconditions.

Variants.

• When variants differ only by parameter ranges → keep one Method with one MethodDescription template.
• When variants differ by Standard (effects/bounds) → either declare a refinement or introduce a distinct Method (context decision).

#Equivalence & compatibility (across notations and contexts)

Within one context.

• Use semantic equivalence (CC‑A3.2‑8) to assert that BPMN vs code vs solver model are the same Method.
• Prefer a short equivalence note showing parity of pre/post/bounds.

Across contexts.

• Treat identity as not guaranteed.
• Provide Bridges (U.Alignment) that map terms, units, roles, and acceptance criteria.
• Be explicit if one spec is only sound (never returns forbidden outcomes) vs complete (can return all allowed outcomes).

Observational perspective (pragmatic). Two specs are observationally equivalent for stakeholders if, under declared conditions, they are indistinguishable by the acceptance tests of that context (even if internal strategies differ).

#Anti‑patterns (and the right move)

• Spec = run. “Yesterday’s process log is our spec.” → The log is Work; write a MethodDescription and link runs to it.
• Who/time in the spec. “Step 3 by Alice at 02:00 daily.” → Use RoleAssigning at run time; schedule via WorkPlan.
• Stuffing BoM. Listing parts/assemblies inside the spec. → Reference interfaces/resources; keep PBS/SBS separate.
• Algorithm‑only bias. Treating code as “real spec” and SOPs as “notes.” → Both are MethodDescription; judge by Standards, not by format.
• Hiding non‑determinism. Solver model with no acceptance criteria. → Declare admissible outcome set and tests.
• Silent parameter capture. Hard‑coding values without declaring parameters. → Declare parameters with ranges; bind at Work creation.
• Undeclared variant drift. Copy‑pasting specs and tweaking silently. → Use VariantOf with stated deltas or declare a refinement.

#Migration notes (quick wins)

1. Label the artifacts. Wherever a repo/diagram/document “is the process,” rename it MethodDescription and link it to a named Method.
2. Extract people and calendars. Move all assignees to RoleAssigning and all schedules to WorkPlan.
3. Introduce parameter blocks. Add a small “Parameters” section with ranges/defaults and safety guards.
4. Write acceptance criteria. Especially for search/optimization or ML specs.
5. Declare equivalence/refinement. Where two notations intend “the same way,” add an equivalence note; where the new one tightens bounds, declare refinement.
6. Bridge domains. If two departments use different vocabularies, add a Bridge (U.Alignment) rather than forcing a single spec.

#Consequences

#Relations

• Builds on: A.3.1 U.Method (the semantic way it describes); A.1.1 U.BoundedContext.
• Coordinates with: A.2 U.Role, A.2.1 U.RoleAssignment (who enacts it); A.2.2 U.Capability (ability thresholds); A.15 Role–Method–Work (linking isExecutionOf to runs).
• Informs: U.WorkPlan (plans reference MethodDescriptions); U.Dynamics (models that specs may assume); Epistemic Role patterns (status of specs RoleStateGraph + State Assertion).
• Lexical guards: E.10.y L‑PROC (do not call MethodDescription “process” when you mean Work/WorkPlan); E.10.x L‑FUNC (avoid “function/functionality” confusion).

#Didactic quick cards

• Spec ≠ Method ≠ Work. Written recipe ≠ semantic way ≠ dated execution.
• Keep people/time out. Assignees → RoleAssigning; schedules → WorkPlan.
• Declare parameters & acceptance. Bind values at Work; state how success is judged.
• Same method, different specs. BPMN/code/solver can be equivalent if pre/post/bounds match.
• Bridge, do not blur. Cross‑team/domain differences go through U.Alignment, not wishful thinking.

#A.3.2:End