A.2.2:6 - Worked Cases

A.2.2:6.1 - Manufacturing Cell

This constructed example states the robot’s ability separately from its assignment:

CapabilityStatement:
  holder: RobotArm_A
  canDo: Weld_MIG_v3 seam family
  envelope: steel grades S235-S355, ambient 18-30 C, argon mix 92-95 percent, torch T-MIG-07
  measures: bead width 6.0 mm plus or minus 0.2 mm, throughput up to 12 seams per minute, defect rate below 0.5 percent
  qualificationWindow: calibration valid through 2026-09-30
  qualificationPolicy: rely on the test and calibration support only within its declared validity
  actualCondition: the robot configuration and calibration state satisfy the claimed envelope
SupportAndUseBasis:
  evidenceOrSourceUse: latest welding test report and calibration source relation

WeldingShiftAssignment is a declared species under U.SystemRoleAssignment. Under A.2.1 its signature defines the holder and assigned-kind participant meanings and uses WelderSystemRoleKindDomain as the local assigned-kind domain; it adds another participant only if that participant changes the assignment predicate or occurrence identity. One occurrence has RobotArm_A as holder, WelderSystemRole as the assigned-kind value admitted by that domain, and an extent lasting while the predicate obtains without interruption for the same participants. The assertion has exact claim content, EntityOfConcern, and effective ReferenceScheme; a ClaimScope, selected slice, interval, or qualification window is stated separately when it changes interpretation or validity. None of those values is another assignment participant. A separate Work or system-locus relation may place intended or performed welding at AssemblyLine_2026 when that relation obtains.

If a Method step requires an obtaining WeldingShiftAssignment whose local kind is WelderSystemRole and bead-width tolerance below 0.2 mm, the assignment and capability are both checked. The declared ±0.2 mm bound does not establish the stricter tolerance, so this capability statement alone cannot support admission of the step.

Shared boundary case — Robot-7 possesses an inspection algorithm. InspectionReleaseAssignment is a declared species under U.SystemRoleAssignment; under A.2.1 its signature defines the holder and assigned-kind participant meanings and uses InspectorSystemRoleKindDomain as the local assigned-kind domain. Occurrence InspectionAssignment-17 has Robot-7 as holder and InspectorSystemRole as the assigned-kind value admitted by that domain. This simple species declares no taxonomy, reference-scheme, generic-context, or interval participant. An assertion about the occurrence may cite MaintenanceRoles-2026, Maintenance-Scheme-A, and the candidate inspection interval as interpretation and description content.

Robot7-TurbineInspectionStatement-2026 is an assertion about Robot-7: that System can perform turbine-inspection Work within the stated sensor, calibration, input and measure bounds. Qualification governs current reliance on its support. A statement that Robot-7 “possesses inspection algorithm A” does not by itself identify that capability claim, Method TurbineInspection@Maintenance-2026, a deployed-software relation, or a MethodDescription episteme.

Dispatch the phrase by claim: use A.2.2 only for the bounded ability; A.3.1 for the Method; a deployed-software or possession relation when that is the claim; and A.3.2 for candidate episteme TurbineInspectionProcedure-v3 only after its EntityOfConcern resolves to that Method and one substantive claim says how it is done.

Assignment and capability still do not prove execution. If InspectionWork-17 actually occurs, A.13 first recovers Robot-7 as the exact actual performer through obtaining InspectionAssignment-17, and A.15.1 independently admits the Work. Because this example expressly states assignment-bound attribution, F.6 afterward establishes performedUnderAssignment(InspectionWork-17, InspectionAssignment-17) through that same assignment; F.6 identifies neither assignment nor performer, and failed attribution leaves the Work intact. The Work occurrence separately stands in enactsMethod(InspectionWork-17, TurbineInspection@Maintenance-2026).

A.2.2:6.2 - Software Service as Deployed System

PlannerService_v4 is a deployed System. In this constructed example, its claimed ability is to return feasible job-shop schedules for 50–500 jobs and 5–40 machines in less than 20 ms in PlantScheduling_2026, with makespan at most 1.05 × L_ref. Makespan is the elapsed time from the common start to the last job completion; L_ref > 0 is the makespan of the declared feasible reference schedule for the same instance. With L_ref = 100 min, 104 min passes this quality bound and 106 min fails. The reference is a comparison baseline, not a proved optimum.

The deployed System is the holder; the algorithm paper and MethodDescription are descriptions. Version, dependencies and input range qualify the ability claim. Measurements can support that claim, and their age can limit current reliance without itself changing the System’s ability.

A.2.2:6.3 - Organization or Team

FinanceDept can close books for eight legal entities under IFRS with ERP v12, staffing at or above six qualified people, and close duration below five business days. That is a capability of the organizational system.

The monthly-close service promise is a promise-content claim. The actual close for March 2026 is performed Work. Staff assignments and their SystemRoleAssignmentStateRelation occurrences are neighboring claims. The capability statement keeps the department’s ability measurable; a management report asserting it is an episteme about the department.

A.2.2:6.4 - Episteme Anti-Case

“ISO 26262 has safety capability” is not an ability claim about a holder System. The standard is an episteme used as source, requirement, or assurance input. A safety engineering team or toolchain may have a capability to perform safety-case work using that standard within a declared envelope.