Skip to content

Residual B.3 composition mismatch: G still aggregated by raw SpanUnion #33

@iqdoctor

Description

@iqdoctor

Outcome (Ontology-first)

This is a residual post-#29 inconsistency, not a reopening of #29.

The current B.3 still contains a categorical mismatch in the law used for G composition: it presents G_eff = SpanUnion({G_i}) as the default aggregate form, even though G is a USM scope object whose composition over essential dependency paths is governed by intersection, with SpanUnion reserved for independent support lines to the same claim.

1) Terms and normalization (scholastic)

  • U.ClaimScope (G): a USM scope object over U.ContextSlice, governed by set algebra.
  • Essential dependency path: a support path whose members are jointly required for the claim.
  • Independent support lines: distinct lines of support to the same claim that do not share the same weakest link.
  • SpanUnion: lawful union operation for independently supported slices, not the default law for essential composition.

Normalization used in this issue: G is treated only as a USM scope object with path-wise composition semantics.

2) Ontology validation

Failure type: categorical, with a concrete overclaim counterexample.

Evidence

Current upstream/main still states:

  • FPF-Spec.md:26247G_eff = SpanUnion({G_i}) constrained by support
  • FPF-Spec.md:26445CC-B3.5 repeats the same law

This conflicts with the already normalized USM semantics in A.2.6, where path-wise scope composition is intersection and SpanUnion is reserved for independent lines of support.

Concrete counterexample

Suppose a composed claim depends essentially on:

  • support A valid only on scope S1 = {dry road}
  • support B valid only on scope S2 = {wet road}

If both A and B are required for the claim, the composed applicability is not S1 ∪ S2; it is S1 ∩ S2, which in this toy case is empty. Using raw union would overstate applicability and publish a claim where no jointly supported slice exists.

3) Logical analysis

  • Hidden assumption: all node scopes may be unioned as long as support exists somewhere in the graph.
  • Hidden assumption: support-constrained union is sufficient to prevent over-generalization even for essential dependencies.
  • These assumptions fail because the distinction between joint necessity and independent alternative support is load-bearing for USM.
  • Salvage by trivialization risk: saying “constrained by support” does not repair the law if the formal default is still raw union of node scopes; the ambiguity remains exactly where the law should be explicit.

4) Modalities separated

  • Alethic / typing: what kind of object G is.
  • Structural / compositional necessity: whether supports are essential or alternative.
  • Deontic: what B.3 is allowed to teach as the canonical aggregate law.

5) Structured argument (premises -> steps -> conclusion)

Premises

  • P1: G is a USM scope object, not a score.
  • P2: for essential dependency paths, USM composition is intersection.
  • P3: B.3 still states G_eff = SpanUnion({G_i}) as the aggregate law.

Steps

  • S1: If P2 holds, then P3 is too broad: it licenses union where only joint support exists.
  • S2: Therefore B.3 currently overstates applicability for some composed claims.

Conclusion

B.3 still contains a residual categorical mismatch in the law of G composition.

6) Minimal repair

In B.3 only:

  1. Replace the default G_eff = SpanUnion({G_i}) formula.
  2. State explicitly:
    • essential dependency path -> intersection
    • independent support lines to the same claim -> SpanUnion
  3. Keep the rest of B.3 untouched unless directly needed to make the new law coherent.

Acceptance expectation

B.3 no longer teaches raw union of node scopes as the default law for G, and becomes consistent with A.2.6 and the already accepted post-#29 ontology.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions