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

Preface node heading:a-19-declared-substrate-interpretive-view-2-problem:24928

#What this page is

This is generated FPF reference text from the specification preface or supporting sections. It helps interpret FPF; it is not FPF Reference product documentation.

#Methodology

Use it to understand how the specification wants to be read, then return to a route, pattern, or work packet for active work. Cite generated IDs only when the wording changes the task decision.

#Content

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?

---

Last Updated: 2026-06-17 — upstream FPF commit 646b0b9b (github.com/ailev/FPF)