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

Link to current text

Published source confirmed at last check

Source changed 2026-10-03 05:29:54 UTC · snapshot created 2026-10-03 05:30:57 UTC · last check 2026-10-03 07:00:10 UTC

A.6.9:4.3 - Judgement and change

Choose the least-committing truthful Bridge kind: Equivalence, Narrower-than, Broader-than, Partial-overlap, Disjoint, or one declared cross-family relation kind. The kind settles relation semantics only.

If a Bridge obtains and a use is proposed, judge that use separately:

  • Partial-overlap can support an affirmative label-use claim when its exact rule preserves the named differences; the Bridge does not grant that use automatically.
  • Disjoint can support a contrastive explanation; a proposed substitution receives negative polarity.
  • Equivalence is symmetric, but A -> B and B -> A are different use claims.
  • Narrower-than and Broader-than orient the semantic relation. Narrower-to-broader is usually easier to warrant, but every use direction still needs its own rule, tolerance, and polarity; recover reliance when someone will rely on that claim.
  • A broader-to-narrower proposal normally requires refined cells and a separately tested Bridge. Another profile over the same broad endpoints cannot make an unsafe use safe by declaration.
  • Type-structure reuse requires a separate claim naming the structural rule and loss tolerance. Matched invariants can support that claim; no CL number grants it.

CL may remain optional evidence shorthand: 0 contradicted, 1 weakly comparable, 2 bounded support with counterexamples, 3 matched stated invariants with no current material counterexample. It is neither profile identity nor a suitability threshold.

Narrate changes by the object that changed:

  1. retargetEndpoint for another source or receiving cell;
  2. replaceBridgeProfile for changed relation-semantic content;
  3. reviseBoundedUseClaim for changed u, d, r, t, effective scheme, or polarity;
  4. retestObtaining for changed endpoint facts or dependencies under the fixed profile;
  5. reopenReliance for changed evidence, currentness, A.10 relation or disposition, or B.3 claim, record, or disposition;
  6. reviseBridgeCard for changed package content;
  7. publishBridgeCardEdition for a publication occurrence; and
  8. recoverReceivingObject when the use is claimed to have happened.

An inverse asymmetric relation and any direct A-to-C relation require their own profiles and tests. Two chained Bridges do not entail a third.