#Trust & Assurance Calculus (F–G–R with Congruence)

B.3 · Stable · Foundational (B) · Normative for FPF use that claims assurance, trust, readiness, compliance, safety, release confidence, F, G, R, or CL for a named 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 for FPF use that claims assurance, trust, readiness, compliance, safety, release confidence, F, G, R, or CL for a named claim.

Plain-English headline. B.3 governs an assurance-result claim about one exact claim episteme for one named assurance use. It conservatively combines formality F, claim scope G, reliability R, and edge-scoped congruence CL without turning evidence, provenance, a dashboard, a status value, an assessment record, or a later decision into assurance by presence. The target fact, its direct result, the claim episteme, assessment work, evidence-use relations, assurance-result claim, witness, record, publication, and later reliance remain separately recoverable.

Use this when. Use B.3 when a receiving work or reliance decision depends on assurance, trust, readiness, compliance, safety, release confidence, F, G, R, or CL for one exact claim episteme.

What goes wrong if missed. A label, dashboard, model card, credential, provenance mark, gate decision, status value, or evidence bundle starts raising trust or readiness without an exact target claim, assessment, evidence-use basis, scope, limitations, decay condition, and named assurance use.

What this buys. The user gets a conservative, contestable assurance-result claim whose inputs and limits can be replayed without changing the target fact or confusing assurance with status, approval, permission, gate passage, currentness, or actual reliance.

First output. Write one typed AssuranceResult(E_C, U_A | RS_A, G_A, T_A) claim for exact target-claim episteme E_C and named assurance use U_A, or write an explicit no-assurance disposition. A publication face, rendering, cue, evidence pointer, wording issue, gate decision, role assertion, status-value assertion, commitment, or work occurrence is not itself an assurance result.

Not this pattern when. Stay with A.2.4 when the question is how an episteme is used as evidence or status support, with A.10/G.6 for source recovery and bounded reliance, with G.11 when currentness changes admissible use, and with F.10 for the status value and its use. When no assurance claim or material-reliance threshold is current, use the exact gate, permission, commitment, work, decision, or domain-result rule that defines or tests the claim actually being made; do not create a B.3 result merely to name its pattern.

Assurance result selection. Use the lightest result that decides the named assurance use. A cue or source pointer gets no B.3 tuple. A local, reversible, non-release, non-compliance, non-safety use may need only a compact bounded assurance-result claim naming E_C, U_A, the evidence-use/provenance refs, limit, and reopen condition. Reserve the full typed result for readiness, compliance, safety, release confidence, trust, explicit F/G/R/CL, material reliance, or reuse as an assurance input.

Assurance claim over time. An assurance-result claim is time-bounded and updateable: it can decay, reopen, narrow, or be withdrawn. Name the drift, monitoring, incident, evidence refresh, version change, policy change, gate change, or residual unsupported-use condition that reopens it. Such a change can alter warrant or admissible reliance while leaving the target fact and target claim identity unchanged.

When a non-trivial result in FPF—a composed system is safe, a model is credible, a conclusion holds—is reused for a consequential assurance purpose, the assurance-result claim must expose the exact result claim and the basis on which that use is warranted.

#Keywords

• trust
• assurance
• reliability
• F-G-R
• formality
• scope
• congruence
• evidence
• claim-support posture
• authority-looking labels
• dashboard tiles
• probe/distributed/export/causal assurance.

#Relations

#Content

#Problem frame

When a non-trivial result in FPF—a composed system is safe, a model is credible, a conclusion holds—is reused for a consequential assurance purpose, the assurance-result claim must expose the exact result claim and the basis on which that use is warranted.

• For a claim whose EntityOfConcern is a U.System holon, assurance evaluates the exact capability, constraint, safety, or reliability claim under stated conditions; it is not a new system state.
• For a claim whose EntityOfConcern is a U.Episteme holon, assurance evaluates the exact content or model claim and its warrant for U_A; it is not an intrinsic quality conferred on the episteme by a citation or evidence item.

To make such claims comparable and auditable across domains, B.3 introduces a Trust and Assurance Calculus that:

• uses a small typed assurance tuple (F-G-R: F and R as characteristics plus G as scope value) governed by conservative propagation rules; this tuple is not a state space,
• accounts for integration quality via Congruence Level (CL) along the edges of a DependencyGraph (B.1.1, A.14),
• and composes these values only through current governing composition, transformation, temporal, and work operators while respecting their declared invariants.

B.3 is conceptual and normative: it defines which assurance components must be published and how they propagate. How those components improve (for example by formalizing, replicating, reconciling, or widening or narrowing scope under declared operation rules) is handled by KD-CAL improvement moves; those knowledge-dynamics references are descriptive, not required to read here.

Mechanism linkage. For law-governed operation families (for example USM and UNM) authored as mechanisms, use A.6.1 — U.Mechanism to publish OperationAlgebra, LawSet, AdmissibilityConditions, and the Transport clause (Bridge-only; CL, CL^k, and CL^plane). All such penalties reduce R_eff only; F and G remain invariant.

Working-Model handshake (alignment with E.14, B.3.5, and C.13). Assurance consumes two inputs declared in the Working-Model assertion layer (CT2R-LOG, B.3.5): the justification declaration validationMode ∈ {postulate, inferential, axiomatic} and, where present, the grounding link tv:groundedBy. Structural claims that aspire to the strongest guarantees rely on Constructive grounding as a constructive-composition narrative referenced via tv:groundedBy. No assurance record or publication defines Working-Model wording or layout; dependence remains downward-only under E.14.

#Problem

Without a disciplined calculus, four chronic failures appear:

1. Trust inflation: Averaging or summing heterogeneous “quality” tags yields aggregates that look better than their weakest parts, violating WLNK.
2. Scale confusion: Mixing ordinal and ratio scales (e.g., averaging F ordinal scale values with numeric reliabilities) produces meaningless numbers.
3. Congruence blindness: Integration quality (how well pieces fit) is invisible; brilliantly strong parts connected by weak mappings produce overconfident wholes.
4. Scope drift: Design-time formalism and run-time evidence are composed into a single score; dashboards then claim “assurance” for a blueprint using run-time data, or vice versa.

#Forces

#Solution — Part 1: The assurance tuple and the universal aggregation skeleton

B.3 defines what the assurance components are, where they are assigned on nodes and edges of the dependency graph, and the shape of the aggregation that any Γ-flavour must honor when producing an assurance result.

#The F-G-R assurance components (typed; F and R as CHR, G as USM)

We standardize two claim-facing characteristics, one claim-scope value, and one integration-relation characteristic. Every value still names its exact bearer, scheme, scope, window, and basis under B.3:4.2-4.3:

1. Formality (F) — how constrained the reasoning is by explicit, proof-grade structure.

   • Scale kind: ordinal (its scale values do not admit arithmetic).
   • Canonical scale values (example): F0 Informal prose - F1 Structured narrative - F2 Formalizable schema - F3 Proof-grade formalism.
   • Monotone direction: higher is better (never lowers assurance when all else fixed).

2. ClaimScope (G) — the declared set of U.ContextSlice values where the result applies.

   • Type: set-valued USM scope value (A.2.6), not a CHR characteristic.
   • Well-typed operations: membership and set algebra (∈, ⊆, ∩, ⋃, SpanUnion, plus declared Bridge translation, widening, narrowing, or refit operation).
   • Scalar proxy (report-only): if a G scope report needs a number, it may publish an explicitly declared CoverageMetric(G); such a proxy must not replace G in norms, gates, bridge semantics, or CL-bearing relation decisions.

3. Reliability (R) — how likely the claim or behavior holds under stated conditions.

   • Scale kind: ratio in [0,1] (or a conservative ordinal proxy when numeric modeling is unavailable).
   • Monotone direction: higher is better.

4. Congruence Level (CL) — characteristic of one exact integration, mapping, calibration, interface, or other admitted relation occurrence: how well its participants fit for the named assurance use.

   • Scale kind: ordinal with a monotone penalty function Φ(CL) where Φ decreases as CL increases.
   • Canonical scale values (example): CL0 tentative guess - CL1 plausible mapping - CL2 validated mapping - CL3 verified equivalence.
   • Interpretation: low CL reduces the credibility of the integration itself (not the parts), and therefore penalizes the aggregate R.

EntityOfConcern and description strict distinction (A.7).

• Assurance components are recorded as value and scope claim components: F and R as characteristics, G as a scope value, while the governing composition, order, temporal, and work patterns keep structure, order, and time distinct.
• Do not smuggle assurance components into structural edges; keep F, R, and CL explicit as CHR metadata and G explicit as a USM scope value.

Assurance shoulders (Working-Model split). Mapping raises TA (typing, fit, and CL). Logical and Constructive contribute to VA (intended relation semantics; constructive-composition identity when its governor admits it). Empirical Validation contributes to LA through exact input-result and evidence-use relations under the named ReferenceScheme, ClaimScope, conditions, and window. These inputs may be cited from an E.14 Working-Model assertion layer, but B.3 does not make the layer, face, or record an assurance result.

#Assurance as a typed result claim

Begin with one exact C.2.1 target-claim episteme E_C: its ClaimGraph states the claim being assured, its EntityOfConcern identifies what that claim concerns, and its effective ReferenceScheme interprets the claim. Any measurement, causal, conformance, status, capability, safety, or other subject result asserted by that ClaimGraph remains with its direct governor. B.3 neither makes that result obtain nor changes claim truth.

For one named assurance use U_A, B.3 may constitute a separate assurance-result episteme whose ClaimGraph contains:

AssuranceResult(E_C, U_A | RS_A, G_A, T_A)
  = <F_eff, G_eff, R_eff, CL_basis, disposition, limitations>

• E_C is the exact target-claim episteme, not a carrier, status tile, evidence item, result record, or bare holon label.
• U_A is the exact readiness, compliance, safety, release-confidence, model-credibility, trust, or other receiving assurance use; it is not proof that later work actually relied on the result.
• RS_A is the effective ReferenceScheme interpreting the assurance-result ClaimGraph. The target claim retains its own effective ReferenceScheme.
• G_A is the A.2.6-governed claim scope for this assurance result. Assumptions, environment, audience, operating conditions, and local sense constraints are stated by value rather than hidden in a generic context field.
• T_A is the declared design/run stance and exact applicability, evidence, or reliance window. Design and run results remain separate.

Keep the following objects distinct whenever they are current:

1. the world-side subject facts and domain-local result under their direct governors;
2. target-claim episteme E_C under C.2.1;
3. each exact A.2.4 evidence-use relation classifying an episteme for a target claim, scope, polarity, window, and intended assurance use;
4. the A.10/G.6 source-provenance path and local RelianceDisposition for the bounded evidence use;
5. dated assurance-assessment U.Work, its performer assignment, enacted method, and exact direct or A.6.1 application bindings;
6. formal, empirical, causal, measurement, conformance, comparison, or other input results and the C.2.1 epistemes that state them;
7. the B.3 assurance-result claim and its distinct C.2.1 episteme;
8. witnesses, calculation traces, an optional assurance record episteme, publication occurrence, form, rendering, and carrier; and
9. any later premise/use relation, reliance decision, F.10 status use, A.21 gate decision, permission, release decision, or performed action.

None of objects 3-9 makes the target fact true. An evidence change may change input availability, warrant, F/G/R/CL, the assurance disposition, or admissible reliance without changing the world-side result or E_C. Absence of evidence is therefore not a negative target result. A status value, successful check, record field, publication, or favorable assurance result likewise does not create the target, approve a release, grant permission, or establish actual use.

A minimally replayable assurance-result ClaimGraph designates:

AssuranceResultClaim:
  TargetClaimEpistemeRef: E_C
  AssuranceUse: U_A
  EffectiveReferenceScheme: RS_A
  ClaimScope: G_A
  TimeStanceAndWindow: T_A
  AssumptionAndConditionRefs:
  F_eff:
  G_eff:
  R_eff:
  CongruenceOccurrenceRefs:
  AggregationRuleRef:
  InputResultClaimRefs:
  EvidenceUseRelationRefs:
  A10OrG6PathRefs:
  AssessmentWorkRef:
  AssessmentMethodAndApplicationRefs:
  WitnessOrCalculationTraceRefs:
  Disposition: pass | bounded | degrade | abstain | evidence-needed | reopen | blocked
  LimitationsAndNotCarried:
  DecayAndReopenCondition:

The ClaimGraph is claim content, not a work log or record schema that performs the assessment. AssessmentWorkRef and application refs must resolve outward to independently governed occurrences. Witnesses support replay; they are not result claims. An optional assurance record cites the result and its basis; it does not become the result or perform the work.

Validation modes (preserved input distinction). When a target claim is published through an E.14 Working-Model assertion, its declared validationMode ∈ {postulate, inferential, axiomatic} is one input to assurance reasoning. postulate calls for the declared empirical audit basis; inferential calls for the exact reasoning basis; axiomatic calls for the exact constructive identity and grounding basis under its direct governors. The declaration, tv:groundedBy pointer, assessment work, result claim, evidence use, and publication remain different objects.

Design versus run (no chimeras). Produce separate assurance-result claims when the target use, assumption set, scope, evidence window, or design/run stance differs. Compare them explicitly; do not compose blueprint formality and runtime evidence into one score.

#Authority-looking labels and dashboard tiles

A badge, label, score, dashboard tile, credential display, provenance mark, compliance-looking mark, model card, datasheet, data card, assurance document, attestation label, assurance-looking note, or generated confidence phrase does not enter assurance calculus or improve F, G, R, CL, readiness, safety, compliance, trust, release confidence, or assurance by display alone.

Adversarial misuse guard. Do not let dashboards with favorable labels, compliance-looking badges, old model cards, provenance labels, assurance-looking documents, or generated confidence phrases supply missing evidence, limitations, scope, decay, or argument for an assurance claim.

B.3 dispositions for such a source or publication face are:

Build a B.3 assurance claim only when the next work occurrence or reliance use depends on a typed assurance claim. The typed assurance claim names:

For a full threshold-bearing assurance result, retain the dated assessment U.Work, capable performer and assignment, enacted Method, and application bindings when their identity bears on replay, competence, conflict, timing, reproducibility, contest, or redress. If evidence was produced by a material analysis or test, keep that evidence-production Work and its result distinct from the assurance-assessment Work and assurance result. A method description, record, witness, publication, or favorable result performs neither work and establishes no later reliance.

Assurance evidence minimization. Cite only the A.2.4 evidence-use relations and minimum A.10/G.6 paths needed for E_C and U_A. Use redacted, hashed, scoped, or role-mediated refs when raw material exposes personal data, secrets, privileged logs, tenant identifiers, security-sensitive traces, incident details, or unnecessary identities; a compact pointer must still preserve enough recoverability to replay the warrant.

Viewpoint prompts for assurance use:

Display guidance for assurance labels: a readiness, safety, compliance, trust, release-confidence, or assurance display should expose E_C, U_A, assessment/result ref, evidence-use/provenance refs, scope, window, limitation, disposition, decay and reopen conditions, and the status, work, gate, permission, decision, or reliance claims not carried. Display is a representation/publication of the result, not the result, assessment, or later use.

Incident-learning fields for assurance overread: visible label, documentation record, attempted assurance claim, missing tuple or evidence-provenance field, assurance claim, work claim, or reliance claim not carried by the assurance tuple, limitation or decay condition that defeated the claim, next legitimate formalization, evidence repair, scope narrowing, or claim narrowing move, and upstream repair record for documentation, evidence refs, assurance label wording, monitoring, or reopen trigger.

Contestability and redress relation: when the B.3 material-reliance threshold is met, the B.3 result should name the claim being contested, evidence-provenance path, limitation or decay condition, contest forum or decision forum, safe interim disposition, and what evidence or scope change would reopen the assurance claim.

If those fields are missing, the encountered publication face, rendering, or cue remains an orientation label, source pointer, evidence pointer, documentation record, or unsubstantiated confidence cue. Use A.15 when the question is whether that lane may guide work or reliance, A.10 when the question is evidence, currentness, or provenance, and A.6 when the question is mixed policy, API, or schema wording.

Positive repaired assurance statement. When the named use and required fields are present, state the smallest AssuranceResult(E_C, U_A | RS_A, G_A, T_A) claim that can guide the use, with assessment ref, exact input-result and evidence-use/provenance refs, argument, limitations, disposition, decay, and reopen condition. It warrants only U_A; any gate, status, permission, performed work, decision, or later reliance remains separately governed. Constructive assurance moves:

• narrow G to the evidenced or rule-bounded scope;
• raise F by formalizing argument structure, method-description fields, or MethodRelationStructure@BoundedContext when method composition, fallback, selection, or method-family relation is current;
• raise R by adding validation, replication, more probative, repeated, current, or more relevant evidence;
• improve CL by repairing mappings, units, interfaces, or integration edges;
• separate design assurance from run assurance;
• add limitations, assumptions, defeaters, monitoring, drift, and reopen triggers;
• reject or downgrade the assurance use when those moves are not available.

Negative controls:

Model cards, datasheets, data cards, assurance documents, and assurance-looking notes are external documentation records or source records unless they are mapped into existing FPF claims and publication faces. They do not add MVPK face kinds and do not bypass B.3 when the use under repair is an assurance claim.

Lint trigger. A model card, datasheet, or data card cited as readiness, safety, compliance, release confidence, or assurance proof requires an exact target-claim episteme, intended-use match, assessment condition, limitations, A.2.4 evidence-use refs, an A.10/G.6 path, and one typed AssuranceResult(E_C, U_A | RS_A, G_A, T_A) claim. Otherwise return no assurance use, a rejected result, or a narrower bounded result.

Positive repaired example: a model card may expose an exact model-claim episteme, intended-use statement, evaluated condition, version, window, limitations, evidence-use refs, A.10/G.6 path, and a separately constituted AssuranceResult(E_C, U_A | RS_A, G_A, T_A). That result may warrant only the named evaluated model use; the card still does not create another deployment claim, gate passage, release work, status, or compliance result.

#Minimum reliance safety assurance record

Use this B.3 section when the B.3 material-reliance threshold is met: reliance on a visible carrier, source reference, publication face, or display may materially change behavior, safety, release, compliance, public or protocol behavior, access, resource allocation, people or team status value, operational action, or controlled-entity regulation. The first B.3 move is to decide whether an assurance claim is being made; if it is, write the minimum reliance safety assurance record for the named reliance use. Mere attention shift, learning, orientation, source-finding, or source-wording correction is not enough.

RelianceSafetyCase is the local Tech label for this B.3 assurance-record form. The plain phrase is minimum reliance safety assurance record. The label is not a new FPF pattern, Core kind, safety authority, gate, policy source, approval, certificate, compliance method, or general safety-case ontology.

Assurance-record use: the trigger/non-trigger table is a recognition aid, the minimum-record table is a local form aid, and the worked slices are examples. They are not a universal checklist, sign-off sequence, status vocabulary, assessment work, or replacement for AssuranceResult(E_C, U_A | RS_A, G_A, T_A). The record cites the assurance-result claim and its independently governed basis; filling it makes no relation obtain.

Affordability card: orientation or source-finding stays outside B.3; bounded local reliance stays with the local evidence, explanation, CV, gate, or pattern-quality relation unless an assurance claim is being made; threshold reliance uses the minimum reliance safety assurance record only when the B.3 material-reliance threshold is met. Plain wording remains ordinary unless it changes a bounded use, source relation, evidence use, gate, assurance claim, work, or decision. Stop after naming the concrete use or relation that changed; no selected pattern locator is required.

Common wrong first classification: a safety-looking note, safety case, compliance-looking label, or dashboard warning is a certificate, approval, or gate. First honest entry: state one typed B.3 assurance claim with A.10 evidence-provenance path, assumptions, limitations, defeaters, residual uncertainty, monitoring or stop condition, contest and redress relation, bounded assurance use, and unsupported attempted use.

First B.3 move: name the reliance use, the assurance claim, the affected context or audience, the trigger that meets the B.3 material-reliance threshold, the A.10 evidence-provenance path, the argument, limitations, defeaters, contest and redress relation, stop or monitoring condition, bounded assurance use, and unsupported attempted use. If those pieces are absent, use A.10, E.17.EFP, A.20, A.21, E.19, or the local relation that actually governs the source use rather than inventing assurance by label.

Trigger and non-trigger cases:

Minimum assurance record:

Positive repaired assurance result: when the threshold is met and the record is sufficient, constitute the smallest assurance-result claim for E_C and U_A, with exact scope/conditions/window, assessment-work ref, input-result and evidence-use/provenance refs, argument, limitations, dependencies, monitoring or stop condition, contest/redress relation, disposition, and unsupported use. The record then cites that result. If insufficient, narrow, degrade, abstain, request evidence, reopen, or block; polished documentation is not safety acceptance.

A safety case is accepted only as a bounded assurance argument for the named reliance use. It remains contestable by defeaters, changed evidence, changed context, monitoring failure, residual-uncertainty breach, or affected-party challenge admitted by the contest relation. Stop when the named reliance use, unsupported attempted use, limitations, defeaters, contest and redress relation, monitoring or rollback condition, and reopen condition are sufficient for this threshold trigger; do not expand the record into a general safety dossier.

Accountable review is insufficient by title alone. It counts here only when it can change the disposition, records the outcome, and leaves the bounded assurance use, unsupported attempted use, and reopen condition inspectable.

Misuse guard: an incoming or attempted-reliance RelianceDisposition=safety-case-required must name the trigger that meets the B.3 material-reliance threshold. A source producer, dashboard-value publisher or maintainer, model producer, documentation producer, or status-value label issuer cannot self-clear a threshold-bearing reliance by attaching the label. Where the B.3 material-reliance threshold is met, the assurance record must expose an accountable review role and a contest relation capable of changing the disposition.

Affected-party contestable minimum: public and protected evidence separation is sufficient only if the affected party can see enough of the claim, source class, disposition, affected use, accountable role, and challenge evidence admitted by the contest relation to challenge the result. Protected evidence reserved for an accountable review role may stay protected, but protected evidence cannot make redress non-contestable while the assurance use still claims contest or assurance relation. A blocked, abstained, degraded, or evidence-needed assurance use is not final if challenge evidence admitted by the contest relation, missing affected-party evidence, changed source, changed context, monitoring failure, or redress can materially change the disposition.

Worked reliance-threshold slices:

Do not treat the assurance record as a graded scale, standalone status value, universal assurance checklist, release certificate, or new safety-case disposition family. B.3 consumes the assurance record only as typed assurance input for the named claim and reliance use.

#Where the values are assigned (and where they are not)

• On exact assurance inputs: every F_i, G_i, or R_i designates the exact target or input claim to which it applies, its bearer under the current characteristic/scope governor, effective ReferenceScheme, scope, time stance/window, and input-result or evidence-use basis. A node, row, label, source file, or evidence item does not receive a value merely by appearing in a graph.
• On exact integration relations: every CL value qualifies one independently established integration, mapping, calibration, interface, or other direct relation occurrence. A drawn edge or Bridge description does not create that occurrence.
• On the assurance result: the aggregation rule yields F_eff, G_eff, and R_eff in the B.3 assurance-result ClaimGraph for E_C and U_A. It does not overwrite the input values, the subject result, or the target claim.
• Not inside Γ: Γ consumes its own admitted inputs and produces its own composed result or holon under the applicable composition pattern. B.3 only evaluates assurance for the named claim about that result; it does not become the composition operator.
• Not work, evidence, status, or a state space: ⟨F,G,R⟩ is neither assessment work, an evidence-use relation, a provenance path, a status value, nor a U.CharacteristicSpace. Do not draw trajectories in it; use ESG and the assurance-trace hooks for separately identified changes in assurance-result claims.

#Universal aggregation skeleton (domain‑neutral)

When a B.3 assessment consumes results organized by a Γ-flavour, its assurance-result claim must adopt the following conservative skeleton; the Γ record itself neither emits nor performs assurance:

1. Formality:

   F_eff = min_i F_i

   Rationale: the least formal piece caps the formality of the whole (WLNK on F). Monotone: raising any F_i cannot reduce F_eff.

2. ClaimScope (G):

   G_eff(path)  = intersection({G_i | i is essential on the dependency path})
   G_eff(claim) = SpanUnion({G_eff(path_j)}) only across independently evidenced paths
   • Along an essential dependency path, every required evidence relation must hold on the same slice, so the effective claim scope is the intersection of the required scopes. Empty intersection means the path does not evidence the claim on any slice.
   • Across independent evidence lines for the same claim, B.3 may publish a SpanUnion of the path scopes, but only when the independence assumption and evidence relation are explicit.
   • Constraint: any region not covered by the required evidence relation for its path is dropped. A raw union of node scopes is never the default law for G.
   • Monotone: adding an independently evidenced path may widen the published claim scope; adding a new essential dependency may narrow it.

3. Reliability (penalized by integration):

   R_raw = min_i R_i                       # Weakest-link cap
   R_eff = max(0, R_raw − Φ(CL_min))       # Congruence penalty
   • CL_min is the lowest Congruence Level (CL) value on any edge in the declared proof path or critical integration subgraph for the claim C.
   • Φ is monotone decreasing and bounded (never makes negative values).
   • Monotone: increasing any R_i or any CL cannot lower R_eff.

4. Evidence-source notes:

   • The aggregation yields values in the assurance-result ClaimGraph. An optional assurance record separately cites all contributing input claims and exact integration relations, their F/G/R/CL values and bearers, assessment-work/application refs, evidence-use/provenance refs, and witnesses. A.10/G.6 own the descriptive paths; G.11 owns any currentness result.
   • The record also cites E_C's ClaimGraph, EntityOfConcern, effective ReferenceScheme, and any separately obtaining empirical-grounding relation; it may present separable TA, VA, and LA input breakdowns, decay/valid-until marks, and the Epistemic-Debt tally without making those presentation fields target facts or evidence-use occurrences.
   • If order or time mattered for the claim, attach the OrderSpec or TimeWindow identifiers (B.1.4).

This skeleton is mandatory. Domain‑specific patterns may add refinements (e.g., separate epistemic “replicability” vs. “calibration”) as long as they do not violate WLNK or MONO and preserve scale kinds.

#System vs. Episteme - same shape, different interpretations

For systems:

• F means engineering discipline (from ad-hoc method to verified specification).
• G means operational envelope coverage.
• R means assured reliability for the exact system claim under the named requirements, environment, test basis, scheme, scope, and time window.
• CL covers interface verification or integration verification.

For epistemes:

• F means logical formality or semantic formality (from prose to proof).
• G means domain span (concepts, populations, conditions).
• R means evidential relation quality (replication quality, measurement integrity).
• CL covers vocabulary mapping quality and ontology mapping quality.

#Scale discipline (CHR guard‑rails)

To prevent silent misuse:

• Ordinal scales (F, CL): never average or subtract; use only min, max, thresholds, and monotone comparisons defined for ordinal scale values.
• Coverage scales (G): use union and intersection in a declared domain space; do not “average” sets. If a numeric proxy is used (e.g., coverage ratio), it must be derived from a set operation, not vice versa.
• Ratio scales (R): may be combined with min, max, or explicitly justified conservative functions; do not combine values across different target claims, effective ReferenceSchemes, scopes, assumption sets, or windows without an exact admitted comparison/translation rule.

#What improves the tuple (improvement-pattern overview)

B.3 remains neutral about how improvement happens, but for didactic clarity:

• Raise F: formalize narratives (specifications, machine‑checked models).
• Raise G: enlarge evidence-covered span (new test regimes, new populations) with adequate evidence.
• Raise R: replicate, calibrate, tighten measurement error, reduce bias.
• Raise CL: reconcile vocabularies, align units, formalize mappings, verify interface Standards.

Each of these corresponds to recognizable U.RoleAssignment values, U.Method or U.MethodDescription changes, evidence-producing U.Work, and improvement moves. Their run-time counterparts are covered by temporal evidence and work-cost evidence under the governing temporal and work patterns.

#Prohibition (normative) — F–G–R is not a CharacteristicSpace

Do not treat ⟨F,G,R⟩ as a U.CharacteristicSpace and do not define geometric trajectories over it. Use ESG for episteme state and the assurance‑trace hooks for trends in assurance tuples.

#Assurance consequence for unsupported causal-use claims

B.3 consumes CausalUseSupportVerdict, CausalEvidenceSupportBasis, and relevant profile refs from C.28 and A.10 when an assurance claim depends on a C.28 causal-use verdict:

CausalUseSupportVerdict = supported | bounded | unsupported | abstain

CausalAssuranceTupleTrigger is narrower than local causal-use repair. A local [C.28](/generated/patterns/C.28) downgrade, redirection to a relation governing the asserted use, or abstain disposition does not require a new [B.3](/generated/patterns/B.3) assurance tuple by itself. Create or update a [B.3](/generated/patterns/B.3) tuple only when the causal-use claim is assurance-bearing, publication-bearing, release-bearing, or reused as an input to assurance, trust, certification, risk acceptance, or downstream selection. Exploratory causal wording, local causal wording repair, or a [C.28](/generated/patterns/C.28) cheap stop remains outside [B.3](/generated/patterns/B.3) until it changes assurance or publication use.

An unsupported causal-use shift lowers, blocks, or abstains from R for the affected causal-use claim. If CounterfactualSamplingRealizabilityProfile.verdict = nonrealizable, [B.3](/generated/patterns/B.3) lowers or blocks R for claims that require direct counterfactual-comparison sampling evidence. If CounterfactualSamplingRealizabilityProfile.verdict = unknown, direct-realization claims are unsupported, while identified, bounded, or simulation-only bounded use may remain available when [C.28](/generated/patterns/C.28) declares the bounded use and unsupported use.

Verdict consequences:

What changes in practice: assurance prose cannot say "high confidence that the policy caused improvement" when the evidence-provenance path only evidences association or simulation-only counterfactual output; the unsupported causal-use step must degrade, abstain, or block the causal-use claim.

What this does not authorize: [B.3](/generated/patterns/B.3) does not determine the [C.28](/generated/patterns/C.28) target CausalityLadderRung, estimand, causal identification, evidence design, or realizability profile; it applies assurance consequences to the CausalUseSupportVerdict supplied by [C.28](/generated/patterns/C.28) and the evidence-provenance path supplied by [A.10](/generated/patterns/A.10).

#Proof obligations for an assurance-result claim

These obligations adapt the current B.1 and B.1.1 dependency-structure and relation-grounding checks for B.3 outputs. They are checks applied in dated assurance-assessment work; their pass/fail claims, witnesses, and optional record remain distinct from both the work and the assurance-result claim. Each Γ-flavour whose result is consumed by a B.3 assurance assessment supplies the applicable basis below; Γ does not emit assurance by itself.

#Common obligations (all Γ-flavours)

• ASS-CLM (Exact target claim and use). Name E_C, its ClaimGraph, EntityOfConcern, effective ReferenceScheme and direct subject-result governor; then name U_A, G_A, assumption/condition refs, and T_A. Do not use a title, carrier, holon label, generic context, or status value as the target claim.

• ASS-WRK (Assessment and result separation). Name the dated assessment work, performer assignment, enacted method, exact rule/application bindings, input-result claims, assurance-result episteme, witnesses or calculation traces, and any optional record/publication separately. A rule, record, or witness does not perform the check or become the result.

• ASS-EVD (Evidence-use and warrant separation). Cite each exact A.2.4 evidence-use relation and the minimum A.10/G.6 path needed for U_A. State polarity, scope, window, rival explanation, reliance disposition, and unsupported use. Evidence availability or loss may change warrant without changing target truth.

• ASS-SCA (Scale discipline). Declare the scale kind and exact bearer for each value: F ordinal, G set-valued scope, R ratio or declared conservative ordinal proxy, and CL ordinal on an exact integration relation. Confirm that every aggregation operation is defined for that scale kind.

• ASS-WLNK (Weakest-link basis). Identify the exact cutset or the declared premise/lemma path, distinguish them when both are used, and cite the input result/evidence-use refs that cap F, G, and R; graph membership alone supplies none of them.

• ASS-CL (Congruence on integration dependency). Identify every direct integration relation occurrence on the relevant path and the exact CL_min used in Φ(CL_min). A mapping label, Card, or description is insufficient.

• ASS-MAN (Replayable assurance record). If a reusable record is needed, let it cite E_C, U_A, RS_A, G_A, T_A, all input result claims and evidence-use refs, F/G/R/CL values and bearers, assessment work and application refs, witnesses, limitations, decay, and an A.10/G.6 path. Include exact OrderSpec or TimeWindow refs when current. The record neither performs the assessment nor creates result truth, assurance, currentness, status, or later reliance.

• ASS-MONO (Declared monotone characteristics). List the characteristics along which a local input improvement cannot reduce the aggregate, and state the exact target/input identity and scope conditions under which that monotonicity claim holds.

#Γ_sys (systems) — additional obligations

• CORE‑BIC (Interface congruence). Reference the Boundary‑Inheritance Standard (BIC) from B.1.2 and record any interface mismatches; these contribute to CL_min.

• CORE‑ENV (Operating envelope). Specify the domain used for G (e.g., load–temperature region) and how coverage is computed (set union constrained by evidence relation).

#Γ_epist (epistemes) — additional obligations

• EPI‑SPN (Entailment path/subgraph). Identify the exact premise or lemma path/subgraph for the claim, including its premises or nodes, inference edges, claim endpoint, scope, and rule selecting that path/subgraph; R_raw = min R_i is taken only over that declared object, not over arbitrary satellites.

• EPI‑MAP (Semantic mapping congruence). Point to the exact vocabulary/ontology mapping relation occurrences and the direct assessment results used to assign their CL values; a verification status label alone supplies neither the relation nor CL.

#Γ\ctx and Γ\method (order‑sensitive) — additional obligations

• CTX‑ORD (OrderSpec). Attach the partial or total order σ and any join-soundness conditions (types, preconditions, and postconditions). (See B.1.4 for NC‑1..3 invariants; B.1.5 adds duration/capability typing.)

#Γ_time (temporal) — additional obligations

• TIME-COV (Coverage and identity). Show that PhaseOf intervals cover the declared window without overlap for the same phased entity; justify any gap or overlap explicitly.

Note on Γ_work. Resource spending and efficiency belong in Γ_work. Their measurement integrity can influence R for a claim (e.g., if a reliability figure depends on calibrated energy input), but costs themselves are not assurance; keep them in Γ_work and cite their measurement assurance as inputs here.

#Archetypal grounding (worked examples)

#System archetype — Battery pack safety claim

• Claim C: Pack P meets discharge current L with thermal safety margin δ in environment K.

• Target and assurance use: exact pack-safety claim episteme under the engineering ReferenceScheme; G_A is the load/temperature/airflow/duty-cycle envelope; T_A = run for the named operational-safety use.

• Graph: Cells ComponentOf modules ComponentOf pack; BIC exposes main power and thermal interface.

• Inputs:

  • F for exact module-spec and cell-test claim inputs: module spec F2, cell test F1 → F_eff = F1.
  • G: operating envelope regions; union constrained by evidence relationed test regimes.
  • R: per‑module reliability from test data; cutset is hot‑spot path near weakest cell.
  • CL: interface congruence (sensor calibration CL2; thermal contact CL1).

• Aggregation:

  • R_raw = min R_i along the thermal cutset.
  • R_eff = max(0, R_raw − Φ(CL_min=CL1)).
  • G_eff: union of evidence-covered (L,T) rectangles, dropping regions lacking validated thermal data.
  • F_eff = min(F_cell=F1, F_module=F2) = F1.

• Assessment and record boundary: dated safety-assessment work consumes the exact calibration/test input-result claims and A.2.4 evidence-use refs; its B.3 result episteme states the tuple, witnesses show the calculation, and an optional record cites the BIC and A.10/G.6 path.

• Improvement move: raise CL (better thermal interface verification), raise F (formal thermal model), add evidenced envelope -> R_eff and G_eff increase monotonically.

#Episteme archetype — Meta-analysis claim

• Claim C: Intervention X reduces outcome O by Δ on population P.

• Target and assurance use: exact meta-analysis claim episteme under the analysis ReferenceScheme; inclusion/exclusion criteria and measurement protocol are condition refs, G_A is population/scope, and T_A = design for the named evidential-credibility use.

• Graph: Studies MemberOf evidence corpus; effect models ConstituentOf synthesis; mappings align different outcome scales.

• Inputs:

  • F: two RCTs at F3, one observational at F2 -> F_eff = F2.
  • R: replication quality per study -> weakest R on the declared entailment path/subgraph caps R_raw.
  • CL: mapping of scales (CL1 vs CL3).
  • G: populations union, but unevidence-covered sub-populations are dropped.

• Aggregation:

  • F_eff = F2 from the weakest study-design evidence relation in the synthesis.
  • R_eff = max(0, min(R_RCT1, R_RCT2, R_OBS) - Φ(CL_min=CL1)).
  • G_eff: union of evidence-covered sub-populations; out-of-scope groups excluded.
  • CL_min = CL1 for the exact scale-mapping relation; cite the mapping witness and weakest-link input claim in the assurance record, while the assurance-result episteme remains separate.

• Assessment and record boundary: dated credibility-assessment work consumes the exact study/effect input-result claims, A.2.4 evidence-use refs, scale-mapping occurrences, bias result, and any constructive equivalence result; the B.3 result episteme, calculation witness, optional record, and A.10/G.6 provenance path remain distinct.

• Improvement move: upgrade mapping verification to CL2 or CL3; increase F via registered analysis plan; replicate lagging study.

#Order-sensitive manufacturing-sequence assurance

• Claim C: The domain manufacturing sequence R, mapped to an order-sensitive Method/Work sequence with an OrderSpec, meets output defect rate <= epsilon.

• Target and assurance use: exact sequence-defect claim episteme; materials and equipment class are condition refs, the manufacturing envelope is G_A, and T_A = run for the named process-reliability use.

• Γ_ctx records: OrderSpec σ for the method/work sequence; declared independent branches; join conditions at inspection.

• Assurance:

  • R_raw = min R_step along the declared order-sensitive dependency path (including inspection effectiveness).
  • Penalty from poor join soundness CL_min.
  • Improvement via faster but verified inspection (increase R_step) or tighter join spec (increase CL).

#Temporal archetype — Model credibility across exact episteme identities

• Claims C_i: each exact model episteme M_i carries its own prediction claim and declared applicability window; a receiving assurance use may additionally ask whether the selected claims jointly support prediction within ±δ over τ.

• Target and assurance use: each exact model claim keeps its own effective ReferenceScheme and window; the selected data regime and drift tolerance are condition refs, and the joint prediction-credibility use declares its own G_A and T_A = run.

• C.2.1 identity and continuity: compare the exact claim content, EntityOfConcern, and effective ReferenceScheme for the items labelled v1, v2, and v3. A changed discriminator identifies another episteme. Assert EpistemeEditionRelation(M_v1,M_v2) or EpistemeEditionRelation(M_v2,M_v3) only when each ordered pair satisfies C.2.1's independent historical-continuation predicate; labels, revision Work, provenance, publication order, and common lineage establish neither occurrence.

• Temporal aggregation: a B.1.4/Γ_time record may order those already recovered edition relations, applicability windows, or publication windows for the bounded assurance use. It does not turn the distinct epistemes into PhaseOf slices. If one exact episteme instead remains unchanged and the use needs proper interval restrictions, A.14 PhaseOf(M@τ_i,M) remains available and B.3 TIME-COV applies to that same phased entity.

• Assurance:

  • compute R_raw = min(R_C1, R_C2, R_C3) only when the named assurance use actually consumes all three exact edition-specific claims and their evidence relations;
  • apply the declared penalty when the mapping or calibration congruence between the edition-specific prediction/evidence bases is low;
  • re-calibration or a new validation campaign may improve the exact supported claim, mapping, or evidence relation, but creates neither episteme identity, edition continuity, currentness, nor publication availability; and
  • a non-continuing replacement receives an independent assurance assessment and inherits no F, G, R, CL, evidence, or reliance result by label.

#Bias-Annotation

B.3 deliberately biases assurance toward conservative aggregation and explicit reliance use. This prevents dashboards, labels, badges, credentials, model cards, provenance marks, or generated confidence phrases from raising trust by appearance. The cost is that assurance claims need typed evidence, scope, limitations, decay, and contestability when they are used for readiness, safety, compliance, release confidence, or other material reliance.

#Conformance checklist

#Common Anti-Patterns and How to Avoid Them

#Consequences

Benefits

• Comparable, conservative, improvable. The tuple ⟨F, G, R⟩ with edge-scoped Congruence Level (CL) values gives a compact, auditable view that improves monotonically under targeted moves (formalize, replicate, reconcile).
• Cross-scale coherence. Works for assemblies and arguments, methods and histories, without leaking order, time, or cost into structure.
• Clear improvement moves. It is obvious what to do to raise each component: raise F, G, or R locally, or raise CL on the integration edge.

Trade‑offs

• More explicit metadata. You must state scale kinds, cutsets, and mapping congruence; this is intentional transparency.
• Conservatism may feel pessimistic. True synergy appears only via MHT or after raising CL—never by arithmetic optimism.

#Rationale

B.3 combines a conservative weakest-supported-part calculus with current assurance-case and assurance-documentation practice. The current comparators below govern only the decisions B.3 actually imports; older and popular sources remain lineage rather than authority by recency, prestige, or display.

#SoTA-Echoing

• Assurance by weakest link reflects reliability engineering and safety cases in complex systems; composing assurance evidence by minima prevents over‑statement.
• Formality and verifiability mirror advances in model‑based engineering and formal verification, where raising F turns subjective arguments into verifiable records.
• Coverage as set and measure follows evidence synthesis and validation practice that treat applicability as a domain region, not a scalar to “average.”
• Congruence on edges captures what meta‑analysis, interface control, and ontology alignment have repeatedly shown: integration quality is often the real bottleneck. Penalizing low‑CL is a principled way to prevent silent over‑confidence while rewarding verified reconciliation.
• Assurance documentation, provenance, and release-status practice treats labels, model cards, datasheets, C2PA provenance marks, SLSA and in-toto attestations, credential displays, generated confidence phrases, and dashboards as scoped documentation or source pointers, not automatic assurance claims. B.3 adopts claim, argument, and evidence discipline and scoped assurance-documentation use, adapts model cards, datasheets, data cards, attestations, provenance marks, dashboards, and generated confidence phrases as possible documentation or evidence inputs for a named assurance claim, and rejects visible-label promotion into readiness, compliance, safety, trust, R, F, G, CL, or release confidence without a typed tuple and A.10 evidence-provenance path.

Decision-bearing currentness account (qualified through 2026-08-04).

Practical result from that safety-case and assurance-documentation practice: safety notes, compliance-looking labels, assurance documents, dashboards, provenance marks, model cards, datasheets, data cards, and generated confidence phrases do not become certificates, approvals, gates, safety acceptance, or assurance by appearance. The local B.3 output is one typed assurance-result claim plus, only when useful, a minimum reliance safety assurance record that cites its assessment, A.2.4 evidence-use and A.10/G.6 provenance basis, assumptions, limitations, defeaters, residual uncertainty, monitoring or stop condition, contest/redress relation, bounded assurance use, unsupported use, and exact reopen conditions.

This arrangement preserves A.11 Parsimony and aligns with A.14, A.7, and A.15 while leaving each domain to supply its exact ReferenceScheme, ClaimScope, conditions, windows, subject results, and use relations without breaking the calculus invariants.

#Relations

• Builds on: C.2.1 for target and assurance-result epistemes; A.2.4 for exact evidence-use classification; A.10/G.6 for source-provenance paths and bounded reliance; A.15.1/A.6.1 for assessment work and applications; B.1/B.1.1 and the current system-composition, temporal, work, and relation patterns for exact input structures and occurrences; A.2.6 for ClaimScope; C.16/C.16.Q for scale/value discipline where applicable; and C.13 for Compose-CAL.
• Coordinates with: E.14 (Human‑Centric Working‑Model) for publication-facing assertion discipline and B.3.5 (CT2R‑LOG) for Working‑Model relation label-meaning and grounding (tv:*, validationMode).
• Coordinates with: C.28 for CausalUseSupportVerdict, CausalityLadderRung, CausalEvidenceSupportBasis, identification profile refs, realizability profile refs, supported causal use, and unsupported causal use; A.10 for the evidence-provenance graph path carrying causal-evidence refs.
• Coordinates with: F.10 for status values and their use; G.11 for currentness; A.15 for work/reliance disposition; A.21 for gates; A.20 for constraint-validity results; permission, commitment, release, and decision patterns for their own results; E.17/E.24.PUB and C.29 for publication/representation; and A.15.PROD only when a separately current inception claim is needed. Cite another domain definition or test only for the concrete contribution it makes to the assurance argument. B.3 governs the assurance-result claim, not those neighboring objects.
• Used by: KD-CAL improvement patterns (to plan improvements), B.4 (Evolution loops that raise F, G, R, or CL over time).
• Triggers: B.2 (Meta‑Holon Transition (MHT): Recognizing Emergence and Re‑identifying Wholes) when genuine new capabilities emerge that change the applicable cutsets or envelopes.

One‑page takeaway. Report assurance as a distinct AssuranceResult(E_C, U_A | RS_A, G_A, T_A) claim with ⟨F, G, R⟩ and exact edge-scoped CL basis; keep the target fact, evidence use, assessment work, witness, record, publication, status, and later reliance separate. Improve assurance by raising F, G, R, or CL—and keep order, time, and cost in their own lanes.

#Assurance relation for quantum-like claims

Quantum-like wording does not raise the claim-assurance requirement by default. A local C.26 modeling note can remain lightweight when it only prevents a representational mistake and is not used for a work-guiding use, reliance use, audit-closure claim, readiness-certification claim, or empirical-superiority claim.

Assurance-relation checks:

1. Decide the claim-assurance requirement before building assurance machinery.
2. If the QL note only prevents a local misinterpretation, keep it as QL-lite with ordinary evidence.
3. If the claim will be reused, state the exact target-claim episteme, named use, local stop condition, A.2.4 evidence-use relations, and A.10/G.6 provenance refs. Add the concrete domain definition, comparison rule, or currentness test only when it changes the reusable claim.
4. If the reuse is for release, readiness, audit, compliance, safety, assurance, or other threshold-bearing reliance, perform the B.3 assessment and constitute a separate assurance-result claim over the exact input results, evidence uses, scope, time window, argument, limitations, disposition, and reopen condition.
5. If the claim says QL is better, faster, more accurate, or uniquely necessary, compare rival models, baseline, claimed mechanism, scope, and loss.
6. State decay conditions and reopen conditions so an old QL-evidenced assurance claim does not silently stay current after new validation observations, changed source records, changed evidence refs, or scope change.

Useful outputs:

• no B.3 assurance use when QL is only a local representational lens;
• a compact bounded assurance claim statement when reuse is modest;
• a full assurance-result claim only when consequence severity or explicit F/G/R/CL reuse demands it;
• a rejected, narrowed, or withdrawn claim when evidence does not carry the claimed assurance use or relying context.

#C.29 mathematical-lens use relation

If a mathematical lens is used as input to assurance, readiness, reliability, release confidence, safety, trust, or engineering justification, B.3 constitutes a separate assurance-result claim for the exact lens-result claim and named use, citing the relevant A.2.4 evidence-use and A.10/G.6 provenance refs plus residual-use limits. A C.29 output remains a lens-use result; mathematical elegance, validation regime, or a declared structure-preserving mapping does not raise assurance by itself. Measurement construction and comparability remain C.16.

#B.3:End

Last Updated: 2026-08-04 — upstream FPF commit 67092138 (github.com/ailev/FPF)