#A.2.2 — U.Capability

Preface node heading:a-2-2-u-capability:2071

#Content

#Context (plain‑language motivation)

In real projects we must answer two different questions:

• “Can this system do X?” — this is about an ability inherent to the system.
• “Is this system assigned to do X here and now?” — this is about an assignment (a Role assignment) inside a bounded context.

Teams frequently blur the two, and then further mix them with how the work is done (the Method) and what actually happened (the Work). U.Capability isolates ability as a first‑class concept so that you can plan realistically, staff responsibly, and audit cleanly.

#Problem (what goes wrong without this concept)

1. Permission ≠ ability. A Role assignment authorizes execution in a context; it does not prove the system can meet the required WorkScope and WorkMeasures.
2. Recipe ≠ ability. A Method says how to do something; it does not guarantee that this holder can meet the target outcomes under the required constraints.
3. Execution log ≠ ability. A past Work record does not, by itself, establish a stable ability; conditions may have been favorable or unique.
4. Cross‑team confusion. Enterprise terms like “capability”, “service”, and the old “function” are used interchangeably; planning, staffing, and assurance become fragile.

#Forces (what we must balance)

#Solution — define the ability explicitly

#A.2.2:4.1 Definition

U.Capability is a dispositional property of a U.System that states its ability to produce a class of outcomes (i.e., execute a class of Work) within a declared U.WorkScope (conditions/assumptions) and meeting stated U.WorkMeasures. It is not an assignment (Role), not a recipe (Method), and not an execution (Work).

One-liner to remember: Capability = “can do (within its WorkScope and measures)”, independent of “is assigned now” or “did do at time t”.

Capability declaration (summary). A capability SHALL declare, as separate items:

• U.WorkScope (Work scope) — the set of U.ContextSlice under which the capability can deliver the intended U.Work (see A.2.6 §6.4);
• U.WorkMeasures — measurable targets with units evaluated on a JobSlice (R‑lane facet);
• U.QualificationWindow — the time policy that governs operational admissibility at Γ_time (R‑lane facet). Note. This separation supersedes the legacy “envelope + measures + validity interval” bundle. Work scope is the set of conditions (USM), not a Characteristic; measures are CHR‑characteristics; capability packages both.

Reminder (measurement & scope). WorkScope is a set‑valued USM object (membership, set algebra) and not a CHR Characteristic; WorkMeasures are CHR Characteristics with declared scales/units. Admission checks these separately (see § 10.3 WG‑2/WG‑3).

#A.2.2:4.2 Conceptual descriptors (not a data schema)

When you describe a capability in a model or a review, anchor it by answering these five didactic prompts:

1. Holder: Whose ability is this? → a specific U.System.
2. Context: In which bounded context were the measures established? → U.BoundedContext (strongly recommended for clarity and comparability).
3. Task family: Ability to do what kind of work? → reference the relevant MethodDescription(s) or method family the system can execute.
4. WorkScope: Under what conditions? → inputs/resources/environment assumptions (e.g., voltage, pressure, ambient, tool head).
5. Performance measures: With what bounds? → CHR‑style measures (throughput, precision, latency, reliability, MTBF…) with ranges/targets.

Optional descriptors that improve trust without adding bureaucracy:

• QualificationWindow: calibration/qualification window for the stated WorkScope (abilities drift).
• Evidence: links to test reports, certifications, prior Work summaries (as Episteme).
• Degradation/upgrade notes: known change points that affect the WorkScope.

Didactic guardrail: Capabilities are stated in positive, measurable terms (“can weld seam type W at ±0.2 mm up to 12/min at 18 °C–30 °C”). Avoid role words (“welder”) or recipe detail (step flows) here.

#A.2.2:4.3 Shorthand for everyday speech

To keep discussions terse yet precise, teams often write:

• “S#17 can <MethodDescription / task family> @ <WorkScope> → <measures>.”
• Or as a bullet in a capability table scoped to a context, e.g., AssemblyLine_2025 Capability Sheet.

This is not a formal notation—just a consistent way to keep the five prompts in view.

#Clear distinctions (litmus tests managers can apply)

Two useful corollaries

• A step in a Method may require a Role; optionally it may also stipulate a capability threshold (e.g., precision ≤ 0.2 mm). assignment and ability are checked separately.
• A promise content clause depends on having the needed capabilities and being assigned/committed to deliver under the clause’s context (bind as U.Commitment when it is an obligation).

#Archetypal grounding (parallel structural and organizational examples)

#A.2.2:6.1 Physical system on a line (structural example)

• Holder: RobotArm_A (U.System).
• Task family: seam welding per Weld_MIG_v3 MethodDescription.
• WorkScope: workpiece steel grades S235–S355; ambient 18–30 °C; argon mix 92–95 %; torch T‑MIG‑07.
• Measures: bead width 6.0 mm ± 0.2 mm; throughput ≤ 12 seams/min; defect rate < 0.5 %.
• Context: AssemblyLine_2025.
• Readable claim: RobotArm_A can execute Weld_MIG_v3 within the stated WorkScope at the stated measures (AssemblyLine_2025).
• What this is not: It is not “the welder”—that is a Role assignment when assigned on a shift. It is not the weld recipe— that is the MethodDescription.

#A.2.2:6.2 Software service in operations (structural, cyber-physical)

• Holder: PlannerService_v4 (deployed system).
• Task family: job‑shop schedule generation per JS_Schedule_v4 MethodDescription.
• WorkScope: 50–500 jobs; 5–40 machines; hard deadlines only; network latency ≤ 20 ms.
• Measures: schedule completion within 0.95 of theoretical optimum (benchmark set), 98 % on‑time delivery in simulation.
• Context: PlantScheduling_2025.
• Use: Steps that “require ScheduleGeneration capability ≥ 0.90 optimality” will only pass if the holder’s capability meets or exceeds that bound.

#A.2.2:6.3 Organizational unit (enterprise sense)

• Holder: FinanceDept (U.System as OrgUnit).
• Task family: period close per CloseBooks_v3 MethodDescription.
• WorkScope: IFRS; ERP v12; 8 legal entities; staffing ≥ 6 FTE; cut‑off rules X.
• Measures: close in ≤ 5 business days; adjustment error rate < 0.2 %.
• Context: OperatingModel_2025.
• Distinction: This is ability; the service promise clause “Provide month‑end close” is the external promise derived from this ability once formally offered.

#Bias‑Annotation (as in cluster‑E patterns)

• Lenses tested: Arch, Prag, Did, Epist.
• Scope declaration: Universal; holder constrained to U.System.
• Rationale: Gives the kernel a clean, reusable ability concept so Role (assignment), Method (recipe), Work (execution), and promise content (external promise clause) do not collapse into each other. Keeps planning talk truthful and checkable without introducing governance machinery here. U.Capability is a dispositional property of a U.System that states its ability to produce a class of outcomes (i.e., execute a class of Work) within a declared U.WorkScope (conditions/assumptions) and meeting stated U.WorkMeasures.

#Conformance Checklist (normative)

CC‑A2.2‑1 (Holder type). A capability belongs to a U.System (physical, cyber, socio‑technical, or organizational). Capabilities are not assigned to U.Episteme.

CC‑A2.2‑2 (Separation of concerns). A capability is not a Role, not a Method/MethodDescription, not a Work, and not a promise content clause (U.PromiseContent). Models SHALL NOT use capability declarations to stand in for assignments, recipes, executions, or promises.

CC‑A2.2‑3 (WorkScope required for operational use). When a capability is used to qualify a step or to support planning, its statement MUST name a WorkScope (conditions/assumptions) and WorkMeasures (targets/ranges). Guards that admit Work MUST test that the holder’s WorkScope covers the step’s JobSlice (i.e., WorkScope ⊇ JobSlice) and that WorkMeasures meet the step’s thresholds, with an explicit Γ_time window bound. Without a WorkScope and measures, a capability is advisory and SHALL NOT be used for step admission or assurance claims.

CC‑A2.2‑4 (Context anchor). Capability statements that drive operational decisions MUST be anchored to a U.BoundedContext (the “Context” whose vocabulary and test norms apply).

CC‑A2.2‑5 (QualificationWindow). When capabilities are used operationally (e.g., to gate Work), the statement MUST carry a QualificationWindow (calibration window, software version window, etc.) and the guard MUST name the Γ_time window used for the check. Outside the QualificationWindow, the claim is not admissible for gating.

CC‑A2.2‑6 (Past work remains past). Updates to a capability statement SHALL NOT retroactively invalidate already recorded Work. Past Work is judged against the capability declaration that was valid at the time of execution.

CC‑A2.2‑7 (Threshold checks are orthogonal to roles). A step that requires both a Role and a capability threshold admits a Work only if both are satisfied: (i) the performer’s Role assignment is active in the step window; (ii) the holder’s capability meets or exceeds the threshold with WorkScope ⊇ JobSlice and within the QualificationWindow at the named Γ_time.

CC‑A2.2‑8 (Derived capabilities). If a capability is claimed for a composite system (assembled by Γ), the claim MUST be stated as a property of that composite holder (not of its parts) with clear dependency notes (e.g., “valid while Subsystem B meets X”). Details of derivation belong to the context’s methodology, not to this definition.

CC‑A2.2‑9 (No capability for epistemes). Algorithms, standards, and documents provide evidence or recipes; they do not “have capability.” Only systems do.

CC-A2.2-10 (Γ_time selector in guards). Scope-sensitive guards (including Method–Work gates) MUST include an explicit Γ_time selector indicating the window W over which ScopeCoverage and WorkMeasures are evaluated.

#Capability thresholds on steps (how A.15 uses this concept)

A step in a Method may define required roles (assignment) and capability thresholds (ability). A Work passes the gate if:

1. assignment check: the Work’s performedBy points to a valid Role assignment that covers the step window and satisfies the role relation (including specialization ≤ inside the context).
2. Ability check: the holder of that Role assignment has a capability whose WorkScope covers the step’s JobSlice (i.e., declared superset) and whose WorkMeasures meet the step’s threshold(s) within Γ_time(W) and while the capability’s QualificationWindow includes W.

Idioms managers can reuse (plain text):

• “S1 requires IncisionOperatorRole and Precision ≤ 0.2 mm (OR_2025 norms) in window W.”
• “S2 requires PlannerRole, WorkScope ⊇ JobSlice[W], and Optimality ≥ 0.90 on JS_Schedule_v4.”

What to avoid:

• Putting “Precision ≤ 0.2 mm” into the Role name. Keep thresholds attached to the step; keep ability on the holder.

#Time and change (calibration, drift, upgrades)

Capabilities are stable but not static. Three simple practices keep reasoning honest:

• Qualification windows. Abilities drift. Put a QualificationWindow on the statement (e.g., “valid for software v4.2; recalibration due 2025-09-30”).
• Change points. Note upgrades/downgrades that affect the WorkScope or measures.
• Snapshot at execution. When Work is recorded, it is implicitly tied to the then‑current capability statement; later edits do not rewrite history (see CC‑A2.2‑6).

Manager’s rule of thumb: if you would reschedule a job after a tool change, the capability statement needs a new window.

#Composition and Γ (how assembled systems “can do”)

Γ builds a new holder (a composite system). Its capability is not the algebraic sum of parts; it is an ability of the whole under its own WorkScope.

• Express at the whole. “Cell_3 can place 12 PCB/min with ±0.1 mm” — that is a capability of Cell_3, not of the pick‑and‑place head alone.
• State dependencies. “Valid while Feeder_A delivers reels at ≥ X; vision subsystem calibrated ≤ 72 h ago.”
• Constructor vs. transformer. The ConstructorRole builds the composite (Γ); the resulting TransformerRole may later act on products. Capability belongs to the holder relevant to the action (builder’s ability vs operator’s ability).

#Interaction with Service Promise Clauses (external promise content)

A service promise clause (a U.PromiseContent) is a consumer‑facing external promise statement. It relies on capability but is not identical to it.

Note. The bare head noun service is polysemic; in normative prose it is treated as an always‑unpack token. Use A.6.8 (RPR‑SERV) to name the intended facet (promise clause vs endpoint vs work vs commitment).

• From capability to service promise clause. You normally derive a service promise clause by taking a capability and fixing the promise outward (e.g., “We guarantee close ≤ 5 days”).
• From service promise clause back to capability. If the promise raises the bar (e.g., tighter SLA), the underlying capability must meet or exceed it under the promise clause’s context.
• Staffing. Delivering on a service promise clause still requires Role assignments; capability alone does not authorize action.

Memory aid: Capability = can do; service promise clause = promise to others that we will do.

#Interaction with Dynamics (laws vs. abilities)

• Dynamics describe how states evolve (models, laws, trajectories).
• Capability says what this system can achieve within an WorkScope.
• Dynamics often serve as evidence or explanatory models for capability but are not the capability itself.

Physics example: an “isothermal process” (process here as transformation) is a Work instance whose path is explained by a Dynamics episteme; a lab rig’s ability to run that path repeatably is its capability.

#Anti‑patterns (and the right move)

• Role‑as‑capability. “Welder role ensures ±0.2 mm.” → Keep role as assignment; put precision in a capability on the holder; put the threshold on the step.
• Recipe‑as‑capability. “We have the ‘Etch_Al2O3’ capability.” → Recipe is Method/MethodDescription; ability is “can execute Etch_Al2O3 within WorkScope E at measures M.”
• Work‑as‑capability. “We did it once, so we can.” → One Work log is not a stable ability; state envelope and measures if you want a capability claim.
• Context‑less claims. “This tool can machine titanium.” → Say where and under what bounds (context + WorkScope + measures).
• Stuffing capabilities into BoM/PBS. Structure lists what it is; capabilities belong to what it can do (the holder), not inside the parts list.
• Service‑as‑capability. “We have the Month‑end Close capability (promise).” → Promise is a service promise clause (U.PromiseContent); ability is internal, promise is external.

#Migration notes (quick wins for existing texts)

1. Underline WorkScopes. For every “can do” sentence, add conditions and measures; otherwise treat it as background color, not a gate.
2. Pull thresholds out of roles. Move “≤ 0.2 mm”, “≥ 0.90 optimality” from role labels into step requirements; leave roles clean (assignments).
3. Pin contexts. Add the bounded context name to each capability table (“Capability Sheet — AssemblyLine_2025”).
4. Snapshot validity. Add a “valid through” column (software version or calibration horizon).
5. Separate recipe/execution. Move flowcharts under MethodDescription, runs under Work; link the capability to the holder with references to those specs.

#Consequences

#Relations

• Builds on: A.1 Holonic Foundation; A.1.1 U.BoundedContext; A.2 Role; A.2.1 U.RoleAssignment.
• Coordinates with: A.3 (Transformation & role masks); A.15 (Role–Method–Work Alignment).
• Constrains: Step design: thresholds belong on steps; BoM/PBS must stay structural.
• Informs: U.PromiseContent definitional pattern (external promises derive from capabilities); U.Dynamics definitional pattern (models used as evidence or predictors); Γ/aggregation (capability of composites is stated at the whole).
• Lexical guards: E.10.x L‑FUNC (do not call capability “function”); E.10.y L‑PROC (do not call capability “process”).

#Didactic quick cards (reuse in specs and slides)

• Capability = can do (within bounds). assignment ≠ ability ≠ recipe ≠ execution ≠ promise.
• Gate every critical step with two checks: badge (Role assignment) + bounds (Capability).
• Write the Context on every claim: context name, WorkScope, measures, QualificationWindow/valid-through.

#A.2.2:End