#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 defines how assurance or trust is assigned, aggregated, and reused for physical systems, epistemes, and publication or evidence records that are used to claim assurance. It uses one typed assurance tuple, F-G-R: F and R as characteristics, G as the scope value, plus edge-scoped CL; the aggregation rules stay conservative, respect the current composition, transformation, temporal, and work invariants named by their governing patterns, and keep the A.7 EntityOfConcern and description strict distinction. It treats the E.14 Working-Model layer as the publication-facing assertion layer for claims, with assurance inputs attached downward from Mapping, Logical, Constructive, and Empirical Validation layers.

Use this when. Use B.3 when a claim, label, dashboard, evidence bundle, model, report, gate decision, or assurance-input package is being used to raise assurance, trust, readiness, compliance, safety, release confidence, F, G, R, or CL for a named claim.

First output. Write one typed Assurance(H, C | K, S) claim per named assurance claim C, or write an explicit no-assurance-claim disposition when the encountered publication face, rendering, cue, evidence pointer, wording issue, gate decision, role assertion, status-value assertion, commitment, or work occurrence does not carry an assurance claim.

Not this pattern when. If the encountered source or publication face is only a cue, action invitation, boundary wording, evidence question, currentness question, gate decision, release decision, role assertion, status-value assertion, commitment, or work occurrence, use A.15, A.6, A.10, A.21, A.20, A.2.1, A.2.8, A.2.9, or A.15.1 as appropriate.

Assurance result selection. Use the lightest assurance result that can decide the assurance use being claimed. A cue or source pointer gets no B.3 tuple. A local, non-release, non-compliance, non-safety, non-reused claim may be written as a compact bounded assurance claim statement that names claim, assurance use carried by the assurance tuple or relying context, evidence pointer, limit, and stop or reopen condition. Reserve a full typed Assurance(H, C | K, S) claim for readiness, compliance, safety, release confidence, trust, F, G, R, CL, or reused assurance input.

Assurance claim over time. Treat an assurance claim as time-bounded and updateable: it can decay, reopen, narrow, or be withdrawn, not remain a one-time checklist result. For model, data, AI, documentation, release, or operational assurance, name the drift, monitoring, incident, evidence refresh, version change, policy change, gate change, or residual unsupported-use condition that reopens the assurance claim.

Every non‑trivial result in FPF—a composed system is safe, a model is credible, a conclusion holds—is a claim that rests on composed evidence.

#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

Every non‑trivial result in FPF—a composed system is safe, a model is credible, a conclusion holds—is a claim that rests on composed evidence.

• For U.System holons, assurance is about capabilities and constraints under stated conditions.
• For U.Episteme holons, assurance is about the quality of evidence relation for a statement or model.

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 node characteristics, one node scope value, and one edge characteristic:

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) — edge property: how well two parts fit (semantic alignment, calibration, interface standard).

   • 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 for structure when the governing pattern admits it). Empirical Validation contributes to LA (evidence in a bounded context). These assurance inputs attach downward from the Working-Model assertion layer (E.14).

#Assurance as a typed claim

B.3 speaks about assurance of a specific typed claim C over a holon H under context K and scope S ∈ {design, run}:

Assurance(H, C | K, S) = ⟨F_eff, G_eff, R_eff, Notes⟩

• C examples: meets load L, argument Q holds, model M predicts within δ.
• K binds assumptions (environment, usage, priors).
• Notes include carrier/source-currentness records, evidence-provenance references (A.10), OrderSpec or TimeWindow where applicable, cutsets, and evidence citations.

This tuple gives practitioners an at-a-glance assurance result while preserving the pieces needed for audit and improvement.

Validation modes (declaration, normative). Each published Working-Model assertion declares validationMode ∈ {postulate, inferential, axiomatic} (E.14).

• postulate -> pragmatic working claim; Empirical Validation is required for audit.
• inferential -> reasoned consequence; Logical assurance carries the reasoning requirement.
• axiomatic -> constructive identity; structural edges provide a constructive-composition narrative and a tv:groundedBy pointer (C.13, B.3.5).

Design versus run (no chimeras). Assurance tuples for design-time and run-time are reported separately and are not composed into a single score; see the Scope drift hazard in B.3:2 and the obligations in B.3:4.6.

#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 move or reliance move depends on a typed assurance claim. The typed assurance claim names:

Assurance evidence minimization. A typed assurance result cites the minimum A.10 evidence path needed for the named assurance claim and relying context. Use redacted, hashed, scoped, or role-mediated evidence refs when raw evidence records would expose personal data, secrets, privileged logs, tenant identifiers, security-sensitive traces, incident details, or unnecessary identities; do not build a full assurance dossier when pointers preserve enough recoverability.

Viewpoint prompts for assurance use:

Display guidance for assurance labels: a readiness, safety, compliance, trust, release-confidence, or assurance display should show the named assurance claim, assurance use carried by the assurance tuple or relying context, evaluation condition, evidence-path ref, scope, window, limitation, decay condition, reopen condition, and assurance, work, or reliance claims not carried by the assurance tuple. A label that only points to documentation should remain a source pointer, not an assurance result.

Incident-learning fields for assurance overread: visible label, documentation record, attempted assurance claim, missing tuple or evidence-path 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 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 assurance use being claimed and the required assurance fields are present, write the smallest typed assurance result that can guide work or reliance: the named claim, context, scope, evaluation condition, evidence path, argument, limitations, decay condition, and reopen condition. That result may improve or justify assurance only for the stated claim and scope; other gate, evidence, work-occurrence, or compliance uses still need their own named sources. 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 documented intended-use match, evaluation condition, limitations, an A.10 evidence path, and one typed Assurance(H, C \| K, S) claim for the named assurance claim. Without those, classify the use as no assurance use or as a rejected or downgraded assurance claim.

Positive repaired example: a model card plus documented bounded-use statement or external intended-use field, evaluation condition, version, window, limitations, an A.10 evidence path, and a typed Assurance(H, C \| K, S) claim may carry assurance for that named model claim in that evaluated context. The same documentation still does not carry another deployment context, gate passage, release work occurrence, or compliance proof unless those sources are separately present.

#Minimum reliance safety assurance record

Use this B.3 section when the B.3 material-reliance threshold is met: reliance on a visible source 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 and non-trigger table is a B.3 recognition aid, the minimum assurance-record table is a minimum local record aid, and the worked reliance-threshold slices are examples for users of the pattern. They are not a universal project checklist, sign-off sequence, untyped status vocabulary, or replacement for Assurance(H, C | K, S); use them only when the named material reliance trigger is met. This local section keeps the attempted reliance inside the B.3 assurance relation; it does not create an extra SEMIO authority or cross-pattern relation vocabulary.

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 bounded use, source relation, evidence, gate, assurance, work, decision, or selected governing pattern.

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 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 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 assurance record is sufficient, write the smallest typed assurance result that can guide the reliance: named assurance claim, reliance use, context, evidence path, argument, limitations, dependencies, monitoring or stop condition, contest and redress relation, bounded assurance use, and unsupported attempted use. When the record is insufficient, narrow the reliance, degrade the assurance use, abstain, require evidence, reopen the source, or block the attempted assurance use; do not convert a polished source into 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 numbers are assigned (and where they are not)

• On nodes: each input holon contributes its local F, G, R according to its nature (system vs. episteme).
• On edges: each integration step has a CL (congruence of the connection).
• Not inside Γ: Γ consumes D and produces a composed holon; B.3 governs how F, G, R, CL propagate to the Assurance tuple for that composed holon. This keeps Γ algebra and assurance calculus separable and reviewable.
• Not a state space: ⟨F,G,R⟩ is an assurance tuple, not a U.CharacteristicSpace; do not draw “trajectories” in ⟨F,G,R⟩. For episteme evolution, use ESG states and the assurance‑trace hooks (see below).

#Universal aggregation skeleton (domain‑neutral)

Any Γ‑flavour that claims an Assurance result must adopt the following conservative skeleton:

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 proof spine or critical integration region 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 aggregate produces an assurance source-currentness record listing all contributing nodes and edges, with their F, G, R, CL, scopes, and evidence links (A.10).
   • The record also displays the EntityOfConcernRef (entityOfConcernRef and groundingHolonRef) and the ReferencePlane for the claim, and presents a separable TA, VA, and LA table of evidence contributions with valid-until or decay marks and the Epistemic-Debt per § B.3.4.
   • 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 under K (requirements, environment, test campaigns).
• 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 add R’s from different contexts without normalization of K (assumptions).

#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 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 path supplied by [A.10](/generated/patterns/A.10).

#B.3:5 Proof obligations (attach these when producing an Assurance tuple)

These obligations refine the generic Proof Kit from B.1.1 §6 for assurance outputs. Each Γ-flavour that emits an Assurance(H, C | K, S) tuple attaches the applicable obligations below.

#Common obligations (all Γ‑flavours)

• ASS-CLM (Typed claim and context). State the claim C (what is being assured), the context K (assumptions, environment), and the scope S ∈ {design, run}.

• ASS‑SCA (Scale discipline). Declare the scale kind used for each characteristic (F ordinal, G coverage, R ratio) and confirm that each operation is defined for that scale kind (no averaging of ordinals; G via set and coverage operations).

• ASS‑WLNK (Weakest‑link evidence). Identify the cutset (node or edge set) that caps F, G, and R for the claim (the proof spine for epistemes, the structural or assurance bottleneck for systems).

• ASS‑CL (Congruence path). Identify the relevant integration path(s) and record CL_min used in the penalty Φ(CL_min).

• ASS‑MAN (evidence-source record). Produce an assurance source-currentness record listing all contributing nodes and edges with (F, G, R) and CL values, their DesignRunTag, and Evidence Graph Ref (A.10). If order or time affect the claim, include the OrderSpec or TimeWindow identifiers from the governing temporal or order pattern.

• ASS‑MONO (Declared monotone characteristics). List the characteristics along which local improvement cannot reduce the aggregate (this is used by future evolution, B.4).

#Γ_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 spine). Identify the premise spine or lemma spine for the claim; R_raw = min R_i is taken along this spine, not over arbitrary satellites.

• EPI‑MAP (Semantic mapping congruence). Point to the vocabulary mappings and ontology mappings used; their verification status sets the CL values on the integration edges.

#Γ\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.

• Context K: Ambient ≤ 35 °C; airflow ≥ X; duty cycle Y. Scope S = run.

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

• Inputs:

  • F per node: 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.

• Evidence/source record: Evidence for calibration, test campaigns, BIC.

• 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.

• Context K: Inclusion criteria, exclusion criteria, measurement protocol; S = design.

• 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 entailment spine 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 scale mappings; record the mapping witness and weakest-link study in the assurance source-currentness record.

• Evidence/source record: Data provenance, scale mappings, bias assessment, and proof-term hash for the effect-model equivalence when it is used constructively.

• 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.

• Context K: Materials, equipment class; S = run.

• Γ_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 — Versioned model credibility

• Claim C: Model M predicts within ±δ over τ.

• Context K: Data regime and drift tolerance; S = run.

• Γ_time records: PhaseOf slices v1, v2, v3 covering τ.

• Assurance:

  • R_raw = min(R_v1, R_v2, R_v3);
  • penalty if v2–v3 interface had low calibration congruence;
  • improvement via re‑calibration (↑CL) or new validation campaign (↑R_v3).

#Conformance checklist

#Anti-patterns and repairs

#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 (informative)

B.3 distills mature post‑2015 practice across several fields into a single, small calculus:

• 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 path.

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 result is one typed assurance claim or minimum reliance safety assurance record for the named reliance use, with A.10 evidence path, assumptions, limitations, defeaters, residual uncertainty, monitoring or stop condition, contest and redress relation, bounded assurance use, unsupported attempted use, and reopen when evidence, source record, context, C.28 identification or realizability profile, A.21 gate profile, evaluation condition, monitoring, or challenge evidence admitted by the contest relation materially changes the disposition.

This arrangement preserves A.11 Parsimony (few characteristics), aligns with A.14, A.7, and A.15 (clear separation of structure, order, time, cost, values), and leaves Context for domain-specific refinements that do not break the invariants.

#Relations

• Builds on: B.1 where its current composition invariants are named by value, B.1.1 (Proof Kit), current system-composition, context, temporal, and work patterns when those operators are active, A.14 (Mereology), A.7 (EntityOfConcern and Description strict distinction), A.10 (evidence-provenance and carrier/source-currentness relations), A.15 (role, method, work-plan, and work alignment), A.2 and A.2.1 (role values and role assignments), A.3.4 (Transformation when actual change is current), and C.13 (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 graph path carrying causal-evidence refs.
• Coordinates with: A.15 for work disposition and reliance disposition, A.6 for mixed authority wording, A.21 for OperationalGate(profile), GateDecision, and DecisionLogRef, A.20 for ConstraintValidity status or witness, and A.15.1 for release or deployment work occurrence. B.3 only handles typed assurance use; labels and evidence pointers stay with the source relation that governs them when assurance is not being claimed.
• 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 ⟨F, G, R⟩ for a typed claim under explicit context and scope, and penalize by the lowest edge-scoped Congruence Level (CL) value. 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 governing FPF pattern, local stop condition, and evidence relation or evidence-path condition.
4. If the claim is used for release, readiness, audit, compliance, assurance, or threshold-bearing work or reliance, build the B.3 assurance claim over named evidence refs and scope.
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 tuple only when consequence severity 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, write the assurance relation in B.3 with the relevant evidence path and residual-use limits. A C.29 output may be cited only as a lens-use result; mathematical elegance, validation regime, or a declared structure-preserving mapping does not raise assurance by itself. Evidence paths remain A.10; measurement construction and comparability remain C.16.

#B.3:End

Last Updated: 2026-06-17 — this section last modified in upstream FPF commit 205de763 (github.com/ailev/FPF)