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

Link to current text

Published source confirmed at last check

Source changed 2026-10-03 17:24:51 UTC · snapshot created 2026-10-03 17:30:20 UTC · last check 2026-10-03 19:30:10 UTC

B.3:10.1 - Decision-bearing SoTA account

Practical questionExact current sourceAdopt, adapt, or reject in B.3Reopen condition
What makes an assurance case inspectable?ISO/IEC/IEEE 15026-2:2022, edition 2 specifies assurance-case structure and maintenance. The GSN Community Standard v3 gives current engineering-argument notation and guidance.Adopt explicit claim, argument, evidence, context, defeater, and maintenance structure. Adapt it to the compact and replay paths. Reject document or diagram appearance as assurance, approval, or permission. This decision shapes 4.1, 4.2, 5, and the dashboard case.A successor changes the required claim-argument-evidence relation or validated use shows that a compact field is missing or redundant.
How may reliability-like inputs be combined?NASA’s Fault Tree Handbook with Aerospace Applications, v1.1, chapter 6, derives AND-event probability from conditional probability and uses a product only under independence.Adopt dependency- and assumption-specific calculation. Reject universal min and any claim that it is always conservative. This decision shapes 4.4 and worked case 6.1.A direct domain model with different validated dependence semantics applies to the current claim.
Can one trustworthiness tuple compare unlike AI or system properties?NIST AI Risk Management Framework 1.0 treats trustworthiness characteristics as context- and use-dependent and recognizes trade-offs and domain metrics.Adopt named characteristics and use-specific thresholds. Reject same-letter cross-domain comparability and monotone formality. This decision shapes 4.3.A validated common measurement model supplies shared bearers, scales, units, and interpretation for the exact properties being compared.
What can provenance and attestation establish?C2PA Technical Specification 2.4 distinguishes provenance validity from value judgments. in-toto Attestation Framework 1.2 defines authenticated metadata about software artifacts.Adopt exact subject, source, binding, and verification claims. Reject a valid credential, manifest, attestation, or display as automatic truth, safety, compliance, readiness, or release. This decision shapes 4.6 and case 6.2.A successor specification changes the property warranted by the artifact or a direct domain rule makes that property sufficient for the named use.

Older assurance-case editions and generic weakest-link slogans are lineage, not decision authority. Popularity, formal appearance, and publication recency do not establish the selected architecture.