#Trust and Assurance Calculus

B.3 · Stable · Foundational (B) · Normative when an FPF use makes an assurance claim about one exact target claim. · Part B - Trans-disciplinary Reasoning Cluster

#About this pattern

This is a generated FPF pattern page projected from the published FPF source. It is canonical FPF content for this ID; it is not a FPF Reference product feature page.

#How to use this pattern

Read the ID, status, type, and normativity first. Use the content for exact wording, the relations for adjacent concepts, and citations to keep active work grounded without pasting the whole specification.

Type: Foundational (B) Status: Stable Normativity: Normative when an FPF use makes an assurance claim about one exact target claim.

Plain-English headline. B.3 helps a practitioner state what an assurance claim is about, which argument and results support it, what use they support, what remains unsupported, and what would reopen the conclusion. It does not turn a badge, evidence item, calculation, record, publication, status, or decision into assurance by appearance.

Use this when. Use B.3 when an actual named assurance claim is current: for example, a claim that an exact model claim is credible for one decision, or that an exact safety claim is adequately supported for one release use.

First useful move. Write the target claim and the assurance use in one sentence. Then ask which direct results and argument make that use supportable. If there is no assurance claim, stop and use the pattern that defines or tests the actual evidence, status, gate, permission, safety, release, work, or domain-result claim.

What goes wrong if missed. A visible label or a convenient score starts raising trust without an exact target, argument, basis, limitation, and use. At the other extreme, a modest assurance question is forced through a universal score and a large record whose fields do not affect the decision.

What this buys. The user gets the smallest assurance result that changes the named use, with enough basis and limits to inspect or reopen it. Domain-specific characteristics and calculations remain usable without pretending that unlike measures share one scale.

Not this pattern when. Stay with A.2.4 for the classification of an episteme as evidence, A.10 and G.6 for source recovery and bounded reliance, G.11 for currentness, F.10 for a status value and its use, A.21 for a gate decision, and the direct domain pattern for safety, permission, access, responsibility, release, compliance, or controlled action. Consequence alone does not create an assurance claim. A direct domain rule may require one, but the claim must be stated before B.3 is applied.

First output. Produce either one bounded AssuranceResult claim or a plain statement that the available argument does not support the attempted assurance use. Do not create a B.3 result merely to record that another pattern is relevant.

Assurance concerns a claim, not the world-side subject in isolation. Begin with one exact target claim, identified by its C.2.1 episteme or ClaimAddress as specified in §4.2, and one named use of an assurance conclusion. The claim's EntityOfConcern remains the system, episteme, method, work occurrence, relation occurrence, or other exact subject identified by its direct pattern.

#Relations

#Content

#Problem frame

Assurance concerns a claim, not the world-side subject in isolation. Begin with one exact target claim, identified by its C.2.1 episteme or ClaimAddress as specified in §4.2, and one named use of an assurance conclusion. The claim's EntityOfConcern remains the system, episteme, method, work occurrence, relation occurrence, or other exact subject identified by its direct pattern.

For example:

• a battery-pack safety fact and its direct test result remain under their safety, measurement, and test patterns;
• the episteme that states the safety claim remains under C.2.1;
• an assurance result states whether a named argument carries that claim for a named release use;
• a later gate, permission, or release decision remains a separate result.

The word calculus here means a disciplined way to select, combine, and interpret the inputs that the assurance argument actually consumes. B.3 defines no universal arithmetic across systems and epistemes.

#Problem

Five failures recur:

1. Assurance by appearance. A badge, dashboard, attestation, card, status, or publication is treated as the assurance conclusion.
2. One scale for unlike properties. Formality, reliability, coverage, congruence, and evidence quality are placed in one tuple even though they have different bearers and scales.
3. Unsupported aggregation. min, an average, a penalty, or another fold is called conservative without a dependency model and calibrated quantities.
4. Process burden by default. Every result is required to name dated Work, Method, assignment, bindings, and a reusable record even when the claim's own basis closes the use.
5. Domain obligations absorbed into assurance. Safety, rights, access, responsibility, contest, redress, status, or controlled-action rules are replaced by a generic assurance record.

#Forces

#Solution

#Start from one assurance question

State these three things before choosing measures or a record:

1. the exact target claim;
2. the named assurance use;
3. the conclusion that must be supported, narrowed, or refused for that use.

Keep the following objects separate whenever they are current:

1. world-side facts and direct domain results;
2. the target-claim episteme;
3. evidence-use relations and source-provenance paths;
4. any assessment Work and the System that performed it;
5. formal, empirical, causal, measurement, conformance, or comparison input results;
6. the assurance-result episteme;
7. calculation traces, witnesses, and an optional note or publication that cites the result;
8. later reliance, status use, gate, permission, release, or action.

Evidence can support or challenge a claim. It does not make the target fact true. A favorable assurance result does not pass a gate, grant permission, or prove that later work relied on it.

#Use the smallest sufficient result

The compact result contains only facts every B.3 use needs:

AssuranceResult:
  targetClaimRef:
  assuranceUse:
  basisRefs:
  disposition: supported-for-use | narrowed | abstain | evidence-needed | reopen | blocked
  limitationsAndNotCarried:
  reopenCondition:

targetClaimRef identifies the exact C.2.1 episteme or one exact C.2.1 ClaimAddress when the use concerns one addressed claim inside a larger episteme. basisRefs cite the direct results, evidence-use relations, provenance paths, argument claims, or domain rules actually used. A compact result is complete when these fields decide the named use and another person can see why the stronger use is not carried.

Add a claim scope, condition set, interpretation scheme, audience, or time window only when changing it could change the conclusion. Keep design and run conclusions separate whenever their inputs or conditions differ.

Add assessment Work, performer, Method, application bindings, witnesses, or a reusable record only when the receiving use depends on competence, conflict of interest, timing, reproducibility, contest, redress, or later replay. These identities are never mandatory merely because B.3 is used.

An optional assurance note may cite the result and its basis. B.3 does not define a reusable RelianceSafetyCase, a safety authority, or a general contest-and-redress profile. If such a reusable object is needed, it requires its own problem, ontology, sources, minimum output, and direct domain boundaries.

#Name each characteristic by its bearer and scale

Include a characteristic result only when the assurance argument consumes it. State:

AssuranceCharacteristicResult:
  bearerRef:
  characteristic:
  scaleAndUnit:
  valueOrInterval:
  interpretationForThisUse:
  basisRef:

One characteristic name must not silently change meaning between subjects. System reliability, replication quality, evidential support, proof inspectability, and relation congruence are different characteristics even when a local source labels several of them R or CL.

The legacy letters F, G, R, and CL may appear inside a declared local scheme, but B.3 assigns them no universal cross-domain meaning:

• Formality or inspectability. Formal structure can make assumptions and inference steps easier to check. It raises assurance only when the named argument explains which uncertainty or verification need it closes. Making a wrong model proof-grade does not improve truth or empirical adequacy.
• Claim scope. U.ClaimScope stays an A.2.6 value. It is not a quality coordinate. Widening or narrowing scope changes the claim and its applicable use under the declared scope rules.
• Reliability-like characteristics. Use the exact domain definition, bearer, population or trials, conditions, scale, unit, and qualification window. A system reliability measure and an evidence-quality judgment are not interchangeable.
• Relation congruence. Characterize one exact mapping, calibration, interface, or other relation occurrence only under a declared scale and interpretation. The value neither changes the participants nor supplies a universal penalty.

Never average ordinal values. Do not subtract an ordinal value from a ratio quantity. Thresholds and order comparisons are valid only under the scale that defines them.

#Aggregate only under an applicable model

B.3 supplies no default fold. When the assurance argument combines quantitative or ordered inputs, cite:

1. the exact result claims being combined;
2. the dependency or alternative-path structure;
3. the domain aggregation rule or model;
4. independence, dependence, calibration, and unit assumptions;
5. the calculation or ordered comparison;
6. the rival rule that would matter if an assumption fails.

Use min only when the cited domain rule makes the weakest input a lower bound or bottleneck for the exact quantity. It is not universally conservative. If no applicable aggregation rule is available, report the inputs separately and return a bounded, non-positive, or unresolved disposition. Do not manufacture one score to make the result look complete.

Several independent evidence lines may strengthen an argument only through the rule that states how their dependence and coverage are handled. Claim-scope intersection or union follows A.2.6 and the relevant evidence model; it is not an assurance arithmetic shortcut.

#Choose one of three proof paths

Compact path. Use the six-field result in 4.2. Stop when it decides the named use.

Calculated or model-bearing path. Add the characteristic results, dependency structure, assumptions, aggregation rule, rival, calculation trace, and sensitivity or failure condition actually used.

Replay path. Add Work, performer, Method, application bindings, witnesses, and a reusable note only when those identities change the named assurance use. For any assessment Work, use A.13 to identify the actual performer and A.15.1 to admit the dated occurrence independently. Add F.6 only if the replay must also say exactly under which assignment the Work was performed. The Work, performer, Method, optional assignment check, result, witness, note, and publication remain separate.

Do not select the replay path merely because the use is important. Importance may make more basis necessary, but every added field must change inspectability, contestability, or the decision.

#Keep visible authority outside the result

A badge, score, dashboard tile, credential display, provenance mark, model card, datasheet, data card, assurance document, attestation, generated confidence phrase, or publication form can be a cue, source, evidence item, or representation. It contributes to assurance only through an exact claim and basis relation used by the argument.

If the visible item only reports a status, gate decision, permission, warning, or source location, use its direct pattern and produce no B.3 result. If an assurance claim is current, cite the item only for the property it actually establishes. A valid signature or provenance chain can establish origin and integrity without establishing safety, truth, compliance, or readiness.

#Leave domain obligations with their direct patterns

B.3 evaluates an assurance claim. It does not define safety duties, access rules, responsibility, affected-party disclosure, contest, redress, people or team status, resource allocation, release authority, or controlled action. Cite each applicable direct rule as a premise or limitation.

When a direct domain rule says a consequential use requires an assurance claim, state that claim and then apply B.3. When the direct rule requires a decision, permission, review, contest route, or redress relation instead, use that result directly. A display that affects behavior does not by itself open B.3.

#Preserve time, currentness, and design/run distinctions

State the exact window only when time changes the assurance conclusion. Monitoring, drift, incidents, evidence refresh, version change, policy change, gate change, or a newly discovered defeater can narrow, reopen, or withdraw a result while the target fact and target-claim identity remain unchanged.

Design evidence and run evidence may support different claims. Produce separate results when target use, conditions, scope, or evidence window differs; compare them instead of merging them into one score.

#Keep causal-use and method-structure branches direct

When an assurance argument depends on a causal-use claim, consume the exact C.28 result and its stated supported and unsupported uses. B.3 does not re-run causal identification. An unsupported causal-use result narrows, blocks, or leaves the assurance claim unresolved; it does not become a low universal reliability coordinate.

When composition, fallback, selection, or family organization among Methods matters to the assurance argument, use A.22 to select the exact structure for that question and use the local designator MethodRelationStructure only for that selected structure. Do not introduce a universal method-relation kind or infer structure from a list of Methods.

#Use Working-Model declarations only for what they state

An E.14 Working-Model assertion may contribute its declared validation posture and grounding links. A postulate still needs the empirical basis required by the current assurance use; an inferential claim needs its reasoning basis; an axiomatic or constructive claim needs the exact construction and identity basis it relies on. The declaration, grounding link, assessment Work, assurance result, and publication remain different objects.

#Proof obligations

#Common obligations

Every positive or narrowed B.3 result:

1. identifies the exact target claim and named assurance use;
2. cites only basis results and relations that actually bear on that use;
3. states assumptions, limitations, and unsupported stronger uses;
4. keeps target fact, claim, evidence, assessment, result, record, publication, and later use distinct;
5. names a reopen condition;
6. uses the direct domain rule for every safety, permission, access, status, release, responsibility, or controlled-action premise;
7. avoids aggregation unless its model and assumptions are explicit.

#Additional obligations for a calculated result

A calculated result also names every bearer, characteristic, scale, unit, dependency, calibrated mapping, aggregation rule, and calculation. It shows at least one assumption whose failure changes the result. If a rival rule is plausible at comparable effort, show why the selected rule fits the declared dependency structure.

#Additional obligations for replay

A replayable result adds only the Work and performance facts needed by the receiving use. Follow the §4.5 replay route for each assessment Work. Add its Method, application binding, witness, timing fact, or separate F.6 assignment check only when competence, independence, reproducibility, contest, or redress actually depends on that fact. No record field stands in for an obtaining relation.

#Worked cases

#Fully calculated case: two necessary independent conditions

Target claim: “The protection function succeeds on a demand.” Assurance use: a bounded reliability argument for a named design decision.

The domain model says that both independently tested conditions must succeed: sensor detection and actuator response. Each has estimated probability 0.9 under the same stated demand class and qualification window. Under the declared independence assumption, the joint probability is:

0.9 × 0.9 = 0.81

Using min(0.9, 0.9) = 0.9 would overstate this conjunction. If the conditions are dependent, even the product is not justified; the result must use the applicable conditional model or remain unresolved. The B.3 result therefore cites the two domain results, the series dependency structure, independence basis, product calculation, 0.81 conclusion, limitations, and the observation that reopens the independence assumption.

What changes in practice: the design decision is evaluated against 0.81, not a falsely “conservative” 0.9. No universal B.3 reliability formula is created.

#Routed-away case: dashboard status

Starting sentence: “The dashboard approves launch.”

The dashboard is a publication face. Suppose it displays GateDecision GD-17, which records that a named gate passed for release candidate R. The repaired sentence is: “The dashboard shows GateDecision GD-17 for release candidate R; the decision, not the display, records that the gate passed.”

Use A.21 and the release or permission pattern that consumes the gate decision. No assurance claim is present, so B.3 stops. If the dashboard does not resolve an exact gate decision, it is only a cue and launch approval remains unresolved.

#Episteme credibility with a compact result

Target claim: “Model edition M predicts response Y within the declared operating region.” Assurance use: whether an engineer may use that prediction as one input to a reversible design comparison.

The engineer cites the exact model claim, its empirical-validation result, the A.2.4 evidence-use relation, the A.10 provenance path, the operating region, and the expiry condition. No combination of unlike characteristics is needed. The compact disposition is supported-for-use, limited to the reversible comparison; release, safety, and operation are expressly not carried. No dated assessment Work or reusable record is added because the use does not depend on who performed the already cited validation.

#Order-sensitive Method case

An assurance argument relies on a manufacturing sequence whose result changes when two steps are reversed. The practitioner uses the direct Method and Work patterns for the sequence and, only because organization among several Methods affects the argument, uses A.22 to select a MethodRelationStructure for that exact question. The assurance result cites the sequence result and selected structure.

#Bias annotation

#Conformance checklist

#Common anti-patterns and repairs

#Consequences

Benefits

• Assurance remains explicit without forcing one cross-domain score.
• A small local claim can stop after six fields.
• Calculations become more trustworthy because assumptions and dependency structure are visible.
• Domain safety, access, responsibility, status, and decision rules retain their own meaning.
• Visible artifacts can contribute useful provenance or evidence without becoming authority.

Trade-offs

• B.3 supplies no convenient universal number. A project must use the domain model that gives its inputs meaning.
• Some assurance questions remain unresolved until a dependency model, calibrated mapping, or direct domain requirement is supplied.
• Reusable replay records cost more than a compact result and therefore require an actual receiver.

#Rationale

Assurance-case practice supports explicit claims, arguments, evidence, and maintenance. Reliability engineering supports calculations tied to dependency structure and assumptions. Neither supports one universal F-G-R-CL score across unlike subjects. B.3 therefore standardizes the boundaries and the minimum result while leaving characteristics and aggregation with the exact models that define them.

#Decision-bearing SoTA account

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.

#Relations

• Builds on: C.2.1 for target and assurance-result epistemes; A.2.4 for exact evidence-use classification; A.10 and G.6 for source-provenance paths and bounded reliance; A.2.6 for ClaimScope; C.16 and C.16.Q for characteristic and scale discipline; and the direct domain patterns for every input result.
• Coordinates with: A.15.1 and A.6.1 only when assessment Work and applications matter; G.11 for currentness; F.10 for status; A.21 for gates; permission, commitment, release, access, responsibility, contest, redress, safety, and controlled-action patterns for their own results; and E.17, E.24.PUB, and C.29 for publication and representation.
• Coordinates with: C.28 for causal-use results and A.22 for a selected MethodRelationStructure when Method organization is part of the assurance argument.
• Used by: a pattern or project decision that consumes one exact assurance result. The consumer still applies its own decision, permission, gate, status, or work rule.

#Quantum-like claims

Quantum-like wording does not require assurance by itself. If the wording only prevents a local representation mistake, keep the note with C.26 and ordinary evidence. Apply B.3 only when an actual assurance claim about that exact quantum-like result and use is current. A comparative superiority claim must name the rival model, baseline, claimed mechanism, scope, evidence, and loss. Mathematical novelty or prestige supplies no assurance.

#Mathematical-lens use

When a C.29 mathematical-lens result is an input to an assurance claim, cite the exact lens-result claim, its interpretation and limits, the evidence-use and provenance relations relied on, and the named assurance use. Mathematical elegance or a structure-preserving mapping does not raise assurance by itself. Measurement construction and comparability remain with C.16.

#B.3:End

Last Updated: 2026-09-10 — upstream FPF commit a87d0ef4 (github.com/ailev/FPF)