fpf.tools
Library / First Principles Framework (FPF) - Core Conceptual Specification
Jump to passage
In this reading
Source · lines 61250–61288

Link to current text

Published source confirmed at last check

Source changed 2026-10-03 11:52:20 UTC · snapshot created 2026-10-03 11:53:41 UTC · last check 2026-10-03 14:15:10 UTC

C.25:17 - Repair and Boundary Notes

C.25:17.1 - Repair from bare quality requirement prose

Bare phrases such as quality requirement, security requirement, or availability requirement should not survive as bare heads when the underlying endpoint is actually a characteristic or bundle. The repair rule is:

  • choose the endpoint shape first,
  • then bind the requirement or commitment to that explicit head.

C.16.Q may still be the entry repair for overloaded quality wording, and C.16.P may repair characteristic, scale, score, metric, or proxy wording inside the same statement; C.25 is the resting place only after the engineering quality family has been made explicit.

C.25:17.2 - Boundary to cross-context use and reliance

Cross-context comparison does not change whether the endpoint is one characteristic or one bundle and does not modify any bundle slot. Align the exact bundle heads or slots and resolve their exact F.17 local senses. Test the direct F.9 predicate when their <ReferenceScheme, LocalSenseClaim> projections differ and the comparison needs semantic correspondence. If a Bridge obtains, state the proposed direction, correspondence rule, tolerated loss, and polarity in a separate bounded-use claim. Observed loss remains evidence; permitted loss remains that claim’s tolerance. Use A.10 for ordinary bounded reliance and open B.3 only when an actual named assurance claim is current.

C.25:17.3 - Boundary to publication convenience

A report, summary publication, or executive summary may express only one slice of the selected quality-claim episteme. Keep the selected episteme and any exact ClaimAddress distinct from its publication occurrence, form, and carrier under E.24.PUB. A coarser form does not collapse the source claim content, while changed Q-Bundle claim content identifies another episteme even when the file or layout stays the same.

C.25:17.4 - Serviceability and supportability

Serviceability, supportability, and adjacent family labels often look simple in prose but become composite as soon as operational use is declared. An admissible bundle for this family may need:

  • support-scope slices,
  • measured restoration or service intervals,
  • mechanism slots for support mechanisms, access discipline, or replacement procedures,
  • and evidence from service traces or support records.

The lesson is the same as elsewhere in C.25: once the truth of the family claim depends on several typed contributors, the bundle should stay explicit.

C.25:17.5 - Boundary to description-side and selector-side evaluation

C.25 is for engineering quality families whose bearer is a system-side, promise-side, or explicit quality-bearing artifact. It does not automatically cover:

  • viewpoint-fit or grounded architecture adequacy claims, which may belong in viewpoint or evaluative-ascription patterns,
  • or selector/objective heads where quality means use-value under a search or portfolio frame.

This boundary matters because the same word quality appears across those zones. C.16.Q repairs overloaded quality wording, C.16.P repairs characteristic, scale, score, metric, or proxy wording when that is the hidden object, and the resting endpoint depends on what is actually being evaluated.