C.25:13 - Decision Test: Single Characteristic or Bundle?

The most common authoring failure is not in the bundle syntax itself; it is in choosing the wrong endpoint shape. The quickest useful test is to ask what would make the quality claim false.

C.25:13.1 - Use one U.Characteristic when

A quality claim should terminate in one admissible CHR characteristic only when all of the following hold together:

• one measurable aspect is actually doing the evaluative work,
• one declared scale is enough to compare relevant cases,
• the bearer and scope are already clear without introducing extra quality slots,
• mechanism or status presence is not itself part of the core quality head,
• and downstream gates can read the claim without needing a bundle decomposition.

Examples include a narrowly declared AvailabilityRatio[%], a specific latency percentile, or one response-time threshold under one fixed window.

C.25:13.2 - Use a Q-Bundle when

A quality claim belongs in C.25 when one family label is standing over several distinct typed concerns, for example:

• several measures are needed together,
• scenario or claim scope is load-bearing,
• mechanism presence or certification state constrains admissibility,
• qualification windows alter the reading materially,
• or one scalar head would hide which part of the family is actually failing.

The bundle is the explicit authoring form for claims whose truth conditions are already composite.

C.25:13.3 - Borderline cases

Some quality families contain both a bundle-shaped form and a narrow single-characteristic form. For example, a service team may use:

• one CHR characteristic for a very narrow uptime commitment, and
• one Q-Bundle for the broader service-availability family that includes scope, windows, failover mechanisms, and evidence.

This is legitimate as long as the text states clearly which head is currently in play. The single-characteristic form does not replace the broader family; it selects one evaluative slice of it.