A.2.2:1 - Problem Frame

These ordinary sentences make different claims about welding:

• “The welding robot is the welder on this line.”
• “The welding robot can weld seam type W at 12 seams per minute.”
• “The welding procedure says how to weld seam type W.”
• “The robot welded batch B at 10:20.”
• “The supplier promises 12 seams per minute.”

Only the second sentence asserts the robot’s ability. Its holder, work family, conditions and measure bounds must be recoverable before the claim can be compared with a demand. The assertion still needs support for the receiving use. The others may state a local system-role assignment, MethodDescription, performed Work, or promise content. When FPF collapses them, project reasoning becomes brittle:

1. System-role assignment becomes fake ability. “Assigned as verifier” is treated as “able to verify”.
2. Method description becomes fake ability. A recipe or algorithm is treated as sufficient evidence of the holder’s ability.
3. Past work becomes fake ability. One successful work occurrence is treated as stable capacity.
4. Promise content becomes fake ability. A service promise hides the real system envelope and measured bounds.
5. Description becomes fake holder. A standard, report, model card, or dashboard is said to “have capability” because it is useful in a capability argument.
6. Unbounded ability becomes unreviewable. “Can machine titanium” does not name conditions, measures, version, calibration, or currentness.