#A.19.DECLARED-SUBSTRATE-INTERPRETIVE-VIEW:10 - Rationale

Preface node heading:a-19-declared-substrate-interpretive-view-10-rationale:25278

#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

The family needs one common interpretive-view pattern because neither of the earlier extremes is good enough.

If everything stays in the substrate, the substrate starts carrying interpretive and atlas-form requirements that are not part of its semantic center.

If everything stays inside one local specialization such as G.2, the common interpretive requirement gets trapped inside one tradition-facing case and starts looking like a local accident rather than a reusable family.

A.19.DECLARED-SUBSTRATE-INTERPRETIVE-VIEW is the middle answer:

• it keeps the interpretive layer generic and reusable;
• it keeps the layer explicitly under existing view law;
• it lets ordinary thinner interpretive views remain first-class;
• and it reserves atlas-form reading for the cases that truly need it.

That is why DeclaredSubstrateAtlasView appears here as one richer interpretive specialization, while TraditionAtlasView remains one G.2 specialization of it rather than the common head.

---

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