#Method Quartet Harmonisation

Pattern F.11 · Stable Part F - The Unification Suite (U-Suite): Concept-Sets, SenseCells & Contextual Role Assignment

“Keep the how (Method), the recipe (MethodDescription), the happening (Work/Execution), and the control push (Actuation) in their own Contexts—then relate them explicitly.”

Status. Architectural pattern. Builds on: E.10.D1 D.CTX (Context discipline); A.3/A.3.1/A.3.2 (Transformer Constitution; U.Method, U.MethodDescription); A.15/A.15.1 (U.Work as record of occurrence); Sys‑CAL (control/actuation semantics); KD‑CAL (observation). Coordinates with. F.1–F.3 (Contexts, Seeds → SenseCells), F.4 (Role Description), F.5 (Naming), F.6 (Role Assignment & Enactment Cycle (Six-Step)), F.7/F.9 (Bridges), F.10 (Status families & Windows). Aliases (informative). Method/Spec/Work/Actuation split; design/run harmonisation.

Intent. Provide a notation‑free, Context‑aware map that keeps four notions distinct and connectable:

#Keywords

• Method
• MethodDescription
• Work
• Actuation
• Role-Method-Work alignment.

#Relations

#Content

#Intent & applicability

Intent. Provide a notation‑free, Context‑aware map that keeps four notions distinct and connectable:

• U.Method — the abstract way of doing (design‑time concept).
• U.MethodDescription — the recipe that describes a Method (epistemic artefact).
• U.Work (informal: Execution) — the run‑time occurrence of doing (recorded event).
• U.Actuation — the control output applied to a plant (domain‑specific Work in Sys‑CAL).

The pattern makes the split usable across FPF patterns (Role Assignment & Enactment, Sys-CAL, KD-CAL, Kind-CAL, planned LCA-CAL) and legible across Contexts (SPEM/BPMN for design; PROV-O/SOSA for run; IEC 61131-3/state-space for control).

Applicability. Any time a discussion risks mixing designs with executions, recipes with runs, or workflow with control signals; whenever you need to name or reason about “how we do X”, “the SOP/script/model”, “the actual run”, or “the actuator push”.

Non‑goals. No team workflow, no editors, no tools. No prescriptive file formats. Only conceptual distinctions and safe reasoning moves.

#Problem frame

When Method, MethodDescription, Work, and Actuation collapse into one another, models drift:

1. Design/run blur. A BPMN process (design graph) is cited as if it had happened.
2. Recipe/approval fallacy. An approved SOP (MethodDescription) is treated as proof that the service met its SLO.
3. Execution ≟ control. PLC task execution logs are conflated with control outputs (actuation), hiding stability issues.
4. Cross‑context homonymy. Activity, task, execution, process, command change sense across Contexts; inferences quietly break.

#Forces

#Core idea (didactic)

Four boxes, four arrows, zero leakage.

• Box 1 — Method (design). The idea of how to achieve an effect (algorithm, clinical pathway, welding technique).
• Box 2 — MethodDescription (design, epistemic). The written/encoded recipe that describes a Method (SOP, code, BPMN/SPEM model, theorem‑prover script).
• Box 3 — Work (run). The occurrence where a System‑in‑Role enacts (some version of) the Method. U.Work is the record of this event.
• Box 4 — Actuation (run, Sys‑CAL). The control output (setpoint/command) issued to influence a plant during Work.

Arrows (conceptual relations).

• MethodDescription ↦ Method (describes) — design stance.
• Work ↦ MethodDescription (followedRecipe? yes/no/variant) — run stance referencing design.
• Work ↦ Method (enacts) — run stance referencing the abstract way.
• Actuation ↦ Work (part‑of / occurs‑during) — control output inside execution.

Each box/arrow is context‑local (SPEM, PROV‑O, IEC…). Cross‑context relations use Bridges (F.7/F.9) with CL/Loss.

#Minimal vocabulary (this pattern only)

• Context = U.BoundedContext (per D.CTX).
• Local‑Sense → SenseCell (F.3): the address (Context × sense) for a term like process, task, activity, command.
• Concept‑Set (F.7/F.8): row aligning multiple SenseCells as “what we regard as the same” (after Bridges & losses are declared).
• Window (F.10): temporal/conditional envelope (e.g., July, during test run T42, under load ≥ 70%).
• StatusCell (F.10): laddered status about methods/specs/works (e.g., Approved (spec); Observed/Measured (work)).

#Solution — the quartet lens (notation‑free)

Not steps for a team—lenses for a thinker. Use them to sanity‑check any statement about “how”, “script”, “run”, or “signal”.

#The stance split (design vs run)

• If the claim is about what should be done or how it is described, you are on the design stance (Method/MethodDescription).
• If the claim is about what happened or what was emitted, you are on the run stance (Work/Actuation).
• Guard rule. Never let a conclusion cross stances without (a) an explicit Bridge kind (interpretation vs substitution), and (b) an acceptable CL (F.7/F.9, F.10).

#The recipe/idea split

• Method is the idea; MethodDescription is the recipe describing that idea.
• Different recipes may describe the same method (profiles, languages, levels of detail); one recipe may encode several methods (composite SOP).
• Naming guard. Keep labels distinct: compressive‑strength test (Method) vs ASTM C39‑18 (MethodDescription).

#The happening (Work) with signal (Actuation)

• Work is the occurrence (a PROV Activity, an IEC Task executing a program, a lab run).
• Actuation is the control output (setpoint, PWM command, valve open %) emitted during Work.
• You can have Work without Actuation (analysis job), or Actuation without a complex Method (manual push). Many scenarios have both.

#The Role Assignment & Enactment touch-points

• Roles (F.4) bind who enacts the Method at run‑time (behavioural masks), not what permissions they hold (RBAC is a different Context).
• Statuses (F.10) bind to the right box: Approved → MethodDescription; Measured/Observed → Work; Satisfied/Violated → Requirement clause about the Work’s outcomes within a Window.

#Harmonisation map (Context‑first)

Examples of local SenseCells and safe Bridges. You may keep the exact Contexts from your F.1 cut.

Design (ideas & recipes).

• SPEM/ISO 24744 Context: SenseCell{Method} = Activity Definition / Task Definition; SenseCell{MethodDescription} = Process Description / WorkProduct (as recipe).
• BPMN 2.0 Context: SenseCell{MethodDescription} = Process (diagram) as design‑time recipe (do not confuse with run).
• OWL/Kind-CAL Context: labels for Method kinds (type taxonomies) when needed (naming, not behaviour).

Run (occurrences & outputs).

• PROV‑O Context: SenseCell{Work} = Activity (time‑bounded occurrence).
• SOSA/SSN Context: Observations about Work results (feeds EvidenceStatus).
• IEC 61131‑3 Context: SenseCell{Work} = Task executes Program (runtime); SenseCell{Actuation} = Output command / setpoint emitted by the program.

Typical Bridges (with intent).

• BPMN:Process (design) ≈ SPEM:Process Definition (design↔design; CL depends on modelling profile; Loss: expressiveness gaps).
• IEC:Task execution ⊑ PROV:Activity (run↔run; Loss: control‑specific timing semantics, scan cycles).
• Actuation (IEC) ⋂ Activity (PROV) (intersection: the sub‑intervals where outputs are emitted).
• SOSA:Observation interprets Requirement clause (F.10) about Work outcomes (cross‑StatusModality: epistemic→deontic; never substitution; declare Bridge(kind=Interpretation, CL, Loss)).

#Invariants (normative)

1. DesignRunTag honesty. Statements about Method/MethodDescription (design) MUST NOT be used as if they were statements about Work/Actuation (run) without an explicit Bridge and Window.
2. Box discipline. Every claim about “how”, “recipe”, “run”, or “control output” MUST point to the correct box in the quartet.
3. Context locality. Terms (process, activity, task, command) MUST be read as SenseCells in their Contexts (F.3); Cross‑context equivalence is a matter for F.7/F.9 Bridges.
4. Status placement. Approved attaches to MethodDescription; Observed/Measured attach to Work; Satisfied/Violated attach to clauses about Work outcomes within a Window (F.10).
5. Actuation as Work‑part. Actuation MUST be modelled as occurring within (or as a specialised form of) Work on the run stance; it does not replace Work.
6. Naming clarity. Technical/Plain labels for the quartet SHOULD be distinct (F.5); avoid homonymous single‑word labels when Contexts collide.
7. Bridge guard. Cross‑context moves MUST declare kind (≈, ⊑, ⊒, ⋂, ⊥, Interpretation), CL, and Loss (F.7/F.9).

#Micro‑examples (didactic)

1. Data pipeline deploy (software). Method: “Delta‑load transform”. MethodDescription: etl_delta.py@v3. Work: nightly run 2025‑07‑14. Actuation: none. Statuses: Spec Approved (governance Context); Work Measured (rows processed) → Evidence for SLO (F.10).

2. Valve control (industrial). Method: PID tuning heuristic. MethodDescription: SOP sheet + IEC program. Work: PLC task cycle 18:00–18:30. Actuation: PWM duty sequence. Bridge: IEC:Task ⊑ PROV:Activity (CL=2). Observed setpoint tracking interprets requirement “settling time ≤ 5 s”.

3. Clinical assay (lab). Method: ELISA. MethodDescription: Kit IFU v7. Work: run batch #B217. Actuation: pipetting robot commands. Statuses: Spec Approved ≠ batch Satisfied (requires evidence at batch Window).

#Anti‑patterns & remedies

#Worked examples (extended)

Each scenario names Contexts (from your F.1 cut), identifies the quartet boxes, and shows safe Cross‑context moves.

#ML service rollout (software + services + sensing)

• Contexts: SPEM/ISO 24744 (design), PROV‑O (run), SOSA/SSN (sensing), ITIL 4 (services).

• Quartet:

  • Method: Canary deployment strategy.
  • MethodDescription: Canary plan document with traffic slices and rollback rules (design Context).
  • Work: Two canary runs 2025‑08‑02 10:00–12:00 (PROV‑Activities).
  • Actuation: Traffic‑shifting commands (if modeled, they are outputs inside Work; optional in pure software).

• Statuses (F.10): Spec Approved; Work Observed (latency/err‑rate via SOSA Observations); SLO clause Satisfied in Window if measured ≤ thresholds.

• Bridge(s): BPMN (if used) Process (design) → PROV Activity (run) Interpretation, CL=2, Loss: path vs time granularity.

Pay‑off: No one infers SLO satisfaction from a plan. Evidence is about Work; the plan stays design‑time.

#Industrial furnace control (control + sensing + services)

• Contexts: State‑space control texts (design), IEC 61131‑3 (run), PROV‑O (run), SOSA/SSN (sensing), ITIL 4 (services).

• Quartet:

  • Method: PID with feed‑forward.
  • MethodDescription: Controller tuning sheet + program description.
  • Work: PLC task cycles 14:00–14:30 (IEC Task executes Program), Bridged as PROV Activity.
  • Actuation: Setpoint & valve duty cycle outputs emitted during Work.

• Statuses: Spec Approved; Work Observed (temperature curve); requirement settling time ≤ 5 s Satisfied if the observation within Window meets it.

• Bridge(s): IEC:Task ⊑ PROV:Activity (CL=2, Loss: scan‑cycle semantics). SOSA:Observation interprets requirement clause (CL=3).

Pay‑off: Separates doing from pushing, and both from measuring; compliance judged where it belongs.

#Clinical assay

• Contexts: SPEM/ISO 24744 (design), Lab assay canon (design/run split as per discipline), PROV‑O (run), SOSA/SSN (sensing).

• Quartet:

  • Method: ELISA.
  • MethodDescription: Kit IFU v7 (instructions for use).
  • Work: Batch B217 performed 2025‑06‑21 (PROV Activity).
  • Actuation: Pipetting robot commands (optional detail).

• Statuses: Spec Approved; Work Observed (absorbance readings); Quality gate Satisfied within batch Window.

• Bridge(s): IFU (design) interprets Activity (run) for acceptance (CL=2, Loss: deviations allowed per kit tolerances).

Pay‑off: A clean line from recipe → run → measurement → decision, without role/status conflation.

#F.11:11.4 Incident response (services + enactment)

• Contexts: ITIL 4 (services/design), BPMN 2.0 (design), PROV‑O (run).

• Quartet:

  • Method: Triage‑first incident handling.
  • MethodDescription: Incident workflow diagram + playbook.
  • Work: Handling INC‑3421, 09:10–10:02 (PROV Activity).
  • Actuation: none (unless modeling command invocations as outputs).

• Statuses: Spec Approved; Work Observed (timestamps, response time); SLO “MTTR ≤ 60 min” Satisfied within the incident Window.

• Bridge(s): BPMN (design) → PROV (run) Interpretation, CL=2, Loss: gateways vs real‑time branching.

Pay‑off: MTTR claims are tied to Work, not to the playbook.

#Reasoning primitives (judgement schemas)

Pure mental moves; no storage or workflow is implied.

1. Box classifier statement s, Contexts fixed ⊢ box(s) ∈ {Method, MethodDescription, Work, Actuation} Reading: Classify any claim by its box (design idea, design recipe, run occurrence, control output).

2. Stance firewall box(s) ∈ {Method,MethodDescription} ⊢ s ∉ {claims about Work outcomes} Reading: A design‑time (stance) statement does not assert a run‑time (stance) outcome.

3. Followed‑recipe judgement Work w, MethodDescription m ⊢ follows(w,m) ∈ {exact, variant, none} Reading: A Work may follow a recipe exactly, with a variant, or not at all; later inferences must respect this value.

4. Enactment link Work w, Method h ⊢ enacts(w,h) Reading: The occurrence enacts the abstract Method (even if several specs describe it).

5. Actuation inclusion Actuation a, Work w ⊢ occursWithin(a,w) Reading: Control outputs are within (or are parts of) a Work interval.

6. Observation binding (KD‑CAL handshake) Observation o about outcome(x) during Window W of Work w ⊢ evidenceFor(w, clause(x,W)) Reading: Measurements about a Work outcome within a Window serve as evidence for clauses about that Work.

7. Clause evaluation (F.10 handshake) evidenceFor(w,clause) ⊢ status(clause,w) ∈ {Satisfied, Violated, Inconclusive} Reading: A clause about Work yields a status via the observation set.

8. Context locality term t, Context C ⊢ meaning(t)@C is local Reading: A term’s sense is local to its Context; Cross‑context claims require Bridges.

9. Bridge application (F.7/F.9) Bridge B: (X@A) ~kind,CL,Loss~ (Y@B); fact about X ⊢ transferableTo(Y) with penalty(CL,Loss) Reading: Facts may transfer across Contexts only along a declared Bridge, with the stated penalty.

10. Version non‑retroactivity MethodDescription m updated → m' ⊢ ∀ past Work w: follows(w,m')=none (unless w references m') Reading: New recipes don’t rewrite history.

11. Composite reasoning MethodDescription m = m1 ; m2, Work w executes steps w1,w2 ⊢ enacts(w1,m1) ∧ enacts(w2,m2) Reading: Composition on design does not force composition on run, but when it aligns you may relate sub‑runs to sub‑methods.

12. SLO locus guard SLO clause about service outcome ⊢ attachesTo(Work-window), not MethodDescription Reading: Service obligations concern what happened within a Window, not the existence of a plan.

#Relations

Builds on: E.10.D1 D.CTX (Context ≡ U.BoundedContext); A.3/A.3.1/A.3.2/A.15 (Method/Spec/Work foundations); Sys‑CAL (Actuation semantics); KD‑CAL (Observation); F.1–F.3 (Contexts → SenseCells); F.10 (Status families & Windows).

Constrains:

• F.4 Role Description: Roles/Statuses must point to the right box (e.g., Approved → MethodDescription; Observed → Work).
• F.5 Naming: Enforce distinct Tech/Plain labels for Method/Spec/Work/Actuation where homonyms threaten.
• F.7/F.9 Bridges: All Cross‑context assertions among quartet terms must go through explicit Bridges with kind/CL/Loss.

Used by. Part C patterns (Sys‑CAL, KD‑CAL, Method‑CAL, Kind-CAL, LCA‑CAL) when describing examples, proofs, and cross‑disciplinary mappings.

#Migration notes (conceptual)

1. Split conflated “process”. Where a single “process” node stands for both plan and run, refactor into MethodDescription (design) and Work (run); add a Bridge if the prose relied on identity.
2. Re‑home statuses. Move any Approval‑like statuses from Work to MethodDescription; move Satisfied/Violated from Spec to clauses about Work within Windows.
3. Expose actuation. If control outputs are buried in “execution logs,” mint Actuation SenseCells and relate them within Work.
4. Version fences. Past Works keep references to the version of MethodDescription they attempted to follow; don’t update those links retroactively.
5. Name collisions. Where task/activity/process appear with mixed meanings, prefix with Contexts and relabel per F.5 (Tech/Plain).
6. Backfill Bridges. If earlier text implied Cross‑context equivalence, add explicit Bridges (F.7/F.9) declaring kind/CL/Loss.

#Acceptance tests (SCR/RSCR — concept level)

#Static conformance checks (SCR)

• SCR‑F11‑S01 (DesignRunTag honesty). Every normative claim about outcomes is attached to Work (with Window), not to Method/MethodDescription.
• SCR‑F11‑S02 (Box placement). Labels and statuses appear on the correct box (e.g., Approved on MethodDescription only).
• SCR‑F11‑S03 (Actuation inclusion). All Actuation statements are modeled as within a Work interval.
• SCR‑F11‑S04 (Context discipline). Each quartet term is expressed as a SenseCell with its Context; no Cross‑context identity is asserted here.
• SCR‑F11‑S05 (Bridge guard). Any Cross‑context reasoning among quartet terms references an explicit Bridge with kind/CL/Loss.

#Regression checks (RSCR)

• RSCR‑F11‑E01 (Spec update). When a MethodDescription changes, previous Works remain valid and unchanged; their statuses don’t shift unless re‑evaluated with explicit rationale.
• RSCR‑F11‑E02 (Bridge drift). If a Context updates, revisit Bridges that touch quartet terms; adjust CL/Loss only via F.7/F.9.
• RSCR‑F11‑E03 (Status drift). Adding new statuses does not move them across boxes (e.g., no new “Work‑Approved”).
• RSCR‑F11‑E04 (Signal creep). Introducing new Actuation details does not erase or replace Work context.

#Didactic distillation (90‑second script)

“When you talk about how something is done, decide which of the four boxes you mean. Method is the idea (the way). MethodDescription is the recipe (the description). Work is the happening (what actually occurred). Actuation is the control push (signals emitted during Work). Keep design and run as distinct stances. Plans and approvals live in the design stance; measurements and obligations live in the run stance within Windows. Words like process, task, activity, command are context‑local—say process (BPMN), activity (PROV), task (IEC). If you must relate them, draw a Bridge and declare its kind, CL, and Loss. For compliance, don’t point at the plan—point at Work, show Observations, and judge clauses in F.10. Hold this quartet in your head and you’ll stop mixing plans with facts, signals with outcomes, and names across Contexts. + Everything else—naming (F.5), U.RoleDescription (F.4) and U.RoleAssignment/U.RoleEnactment (A.2.1/F.6), Bridges (F.7/F.9)—falls into place.

#F.11:End