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

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:15:14 UTC

A.19.DECLARED-SUBSTRATE-INTERPRETIVE-VIEW:2 - Problem

How should one declare a interpretive view so that:

  1. it is explicitly one domain-specific use-site of existing U.EpistemicViewing and U.MultiViewDescribing law, not one fresh autonomous theory of views;
  2. it keeps the already-declared substrate recoverable instead of replacing it;
  3. it allows both ordinary thinner interpretive views and one fuller atlas-form interpretive view;
  4. it keeps OutcomeMapRef, SpaceMetricRef, TransitionRelationRef, and BridgeDistortionNote optional and substrate-side only;
  5. it keeps derived palette or tradition views recoverable through DerivedViewKind and BasePaletteRef when those are active;
  6. it does not mint new set-result family heads, selector policy, publication policy, or shipping semantics;
  7. it lets G.2 keep TraditionAtlasView as one local specialization rather than as the generic head of the whole family;
  8. and it fails closed when the line would really be retargeting, new view-law work, substrate repair, publication, or policy?