A.19.SOURCE-SET-SPACE-SUBSTRATE:0 - Use this when

Preface node heading:a-19-source-set-space-substrate-0-use-this-when:33066

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

Use this pattern when one working line depends on all of the following at once:

  • one declared source set still matters and must stay recoverable by name;
  • one search-side space reference and one outcome-side space reference must both be explicit;
  • the line must say whether those refs resolve to one declared CharacteristicSpace or to two distinct declared CharacteristicSpace declarations;
  • the source-to-outcome relation is load-bearing enough that the reader must know what is being related, in which direction, and through which declared carrier, declared map ref, or qualifier ref;
  • and distortion, uncertainty, or error cannot be left as vague atmosphere.

This is the right pattern for QD, OEE, archive/front, or adjacent synthesis lines when the problem is no longer only "what space exists?" and not yet "what shortlist or shipped result do we publish?".

Not this pattern when:

  • you only need to declare or compare CharacteristicSpace itself, with no source-set or source-to-outcome requirement; use A.19;
  • you are publishing selector or shipping metadata such as SelectorOutcomeKind, SetResultFamily, HandoffKind, or public shortlist identity; use G.5 or G.10;
  • you are building one interpretive view over an already-declared substrate; use A.19.DECLARED-SUBSTRATE-INTERPRETIVE-VIEW or a local specialization such as G.2;
  • you are deciding live pool policy, frontier retention, or next-move planning; use C.19 or C.24.

A.19.SOURCE-SET-SPACE-SUBSTRATE:0.1 - What goes wrong if missed

If this pattern is missed, authors usually collapse several different things into one vague "space" or one vague "projection":

  • the declared source set disappears behind bare words such as front, archive, palette, or portfolio;
  • SearchSpaceRef and OutcomeSpaceRef never become explicit, or SpaceRefRelationKind never becomes explicit, so one line silently hides whether search and outcome use one declared space twice or two different declared spaces;
  • DescriptorMapRef or DistanceDefRef gets mistaken for the space itself rather than one representation or metric qualifier;
  • publication metadata in G.5 or G.10 starts standing in for substrate semantics;
  • and distortion, uncertainty, or error is either hidden or treated as if every non-trivial case were only one bridge-loss story.

The result looks tidy, but the reader cannot tell what is being searched, what is being evaluated, what is only being published, and where uncertainty actually enters.

A.19.SOURCE-SET-SPACE-SUBSTRATE:0.2 - What this buys

This pattern buys one conservative but expressive substrate declaration:

  • the active source set stays visible;
  • the search-side and outcome-side references over A.19 spaces stay distinct;
  • the relation between those refs becomes inspectable instead of being hidden in one overloaded noun or verb;
  • heavier qualifier refs remain available without being forced into every case;
  • and interpretive-view or publication neighbors can reuse the substrate without changing what it means.

The practical payoff is simple: readers can tell what the line is acting on, what relation between the two space refs it assumes, what kind of qualification they must keep in view, and which neighboring pattern governs the next use or action if that requirement grows.


Last Updated: 2026-10-12 — upstream FPF commit f2bc67dd (github.com/ailev/FPF)