#A.19.SOURCE-SET-SPACE-SUBSTRATE - Source-Set and Search/Outcome-Space Substrate

Preface node heading:a-19-source-set-space-substrate-source-set-and-search-outcome-space-substrate:24282

#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

Type: Architectural (A) Status: Stable Normativity: Normative

Plain-name. Source-set / search-outcome-space substrate.

Declared relation-and-ref-position stack. The declared relation-and-ref-position stack that links one recoverable source set to search-side and outcome-side references over A.19 CharacteristicSpace, states how those two refs relate, and makes the source-to-outcome relation plus its distortion, uncertainty, or error posture explicit enough to guide use.

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

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 move if that requirement grows.

#A.19.SOURCE-SET-SPACE-SUBSTRATE:0.a - TERM/LEX token-status guard (local-first)

Keep this token-status split explicit:

• CharacteristicSpace is the reused A.19 kind. This pattern does not mint a second space kind.
• SearchSpaceRef and OutcomeSpaceRef are role-named local fields whose slot content is typed by the existing CharacteristicSpaceRef / SpaceRef idiom. They are not new heads, not slot aliases inside the space, and not U.Role claims. In source-set/space-substrate or typed-set-view passages, read them as role-specific refinements of that older SpaceRef idiom rather than collapsing the roles back into one umbrella SpaceRef.
• SpaceRefRelationKind is a local relation-kind field over those two refs. In this slice, sameDeclaredSpaceAs and distinctDeclaredSpaceFrom are controlled token values for that field, not free prose.
• SourceToOutcomeRelation and DistortionPosture are local declaration fields. Their field names do not by themselves create one new generic ontology; the declaration requirement is satisfied only when their payload is explicit enough to audit.
• SourceSetFamily, SourceSetComposition, and DerivedViewKind are local fields in this SourceSetSpaceSubstrate declaration. Whether any value later becomes a broader stable head is outside this pattern.
• BasePaletteRef, OutcomeMapRef, SpaceMetricRef, TransitionRelationRef, BridgeDistortionNote, DescriptorMapRef, and DistanceDefRef are guarded neighboring refs or interpretive qualifiers reused here. This pattern may cite them, but it does not redefine them.
• carrier inside SourceToOutcomeRelation names the declared line, declared object, or neighboring declared map ref / qualifier ref through which the relation is being realized in this local record. It is not a claim that the thing is U.Carrier.

#A.19.SOURCE-SET-SPACE-SUBSTRATE:0.b - First-minute operator cue and confusion guide

If you are about to write one line that says what is being searched, what is being judged, and whether those two relations sit in one declared space or in two declared spaces, stop and fill this pattern before you write any more umbrella prose such as space, projection, portfolio, or front.

Do this in the first minute:

1. Name the active source set.
2. Point SearchSpaceRef and OutcomeSpaceRef to declared CharacteristicSpace.
3. Choose sameDeclaredSpaceAs or distinctDeclaredSpaceFrom.
4. State the source-to-outcome relation in direction, mode, and carrier.
5. State the governing posture token.

If one of those five cells cannot yet be filled honestly, do not improvise around it. Either you are still in A.19, or you have really moved into interpretive-view work, publication, or policy, or the current line is still missing one declared basis.

Common confusion to kill early: DescriptorMapRef, distance definitions, and OutcomeMapRef values may discipline the line, but they do not answer the first-minute substrate question unless the five cells above are already filled.

#A.19.SOURCE-SET-SPACE-SUBSTRATE:1 - Problem frame

In many search, synthesis, and source-set/space-substrate lines, the live substrate-bearing line is not just one CharacteristicSpace and not just one published shortlist or archive either. The line actually depends on a stack such as:

• one declared source set, for example one front, archive, palette, or another declared source-set family;
• one search-side reference to an A.19 CharacteristicSpace;
• one outcome-side reference to an A.19 CharacteristicSpace;
• one explicit SpaceRefRelationKind over those two references, stating whether they resolve to the same declared space or to two different declared spaces;
• one relation from the source-side line into the outcome-side line;
• and one declared posture about whether that relation is transparent, approximate, learned, lossy, uncertain, or otherwise qualified.

Without an explicit substrate declaration for that stack, nearby declarations start carrying loads they are not meant to carry. A.19 gets stretched from space typing into source-set governance. C.18 descriptor maps start masquerading as the whole search space. G.5 and G.10 publication fields start reading like ontology. Interpretive views or atlas views drift into default meaning instead of staying optional derived help.

#A.19.SOURCE-SET-SPACE-SUBSTRATE:2 - Problem

How should one declare a source-set and search/outcome-space line so that:

1. the declared source set remains explicit and recoverable;
2. SearchSpaceRef and OutcomeSpaceRef stay guarded refs to declared A.19 CharacteristicSpace, not new free-floating space kinds;
3. the text states whether those refs point to one declared space or to two distinct declared spaces;
4. the source-to-outcome relation is explicit enough for the reader to know which source-to-outcome relation mode is being claimed: mapped, projected, translated, scored, or otherwise connected;
5. distortion, uncertainty, and error are stated honestly rather than hidden in prose;
6. SourceSetComposition and DerivedViewKind remain conditional fields rather than fabricated mandatory baggage;
7. qualifier refs such as OutcomeMapRef, SpaceMetricRef, TransitionRelationRef, and BridgeDistortionNote remain available but substrate-side only;
8. and neighboring declarations such as A.19, C.18, G.5, G.10, and A.19.DECLARED-SUBSTRATE-INTERPRETIVE-VIEW can dock to the substrate without redefining it?

#A.19.SOURCE-SET-SPACE-SUBSTRATE:3 - Forces

#A.19.SOURCE-SET-SPACE-SUBSTRATE:4 - Solution

Declare the source-set or search/outcome-space line through one explicit substrate stack, keep only the load-bearing core mandatory, and place every heavier requirement in conditional fields, interpretive qualifiers, or companion declarations.

#A.19.SOURCE-SET-SPACE-SUBSTRATE:4.1 - Declared relation-and-ref-position stack and outside work

Use this pattern to declare only the substrate stack below:

• the declared source set that the line is acting on;
• the recoverable concrete source-set identity when the family name alone would be ambiguous;
• the search-side reference to one declared A.19 CharacteristicSpace;
• the outcome-side reference to one declared A.19 CharacteristicSpace;
• the explicit SpaceRefRelationKind over those two ref positions;
• the explicit source-to-outcome relation;
• and the explicit distortion, uncertainty, or error posture for that relation.

Do not use this pattern to declare:

• A.19 space typing itself;
• selector outcome publication, shortlist identity, or shipping closure;
• live pool policy or enactment planning;
• or optional interpretive-view families that interpret or reorganize an already-declared substrate.

#A.19.SOURCE-SET-SPACE-SUBSTRATE:4.2 - Minimal declaration stack

Use the following notation-independent stack:

SourceSetSpaceSubstrate := <
  SourceSetFamily,
  SourceSetRef?,
  SearchSpaceRef,
  OutcomeSpaceRef,
  SpaceRefRelationKind,
  SourceToOutcomeRelation,
  DistortionPosture,
  SourceSetComposition?,
  DerivedViewKind?,
  BasePaletteRef?,
  OutcomeMapRef?,
  SpaceMetricRef?,
  TransitionRelationRef?,
  BridgeDistortionNote?
>

Interpret the fields as follows:

• SourceSetFamily names the primary declared source-set family that the line is anchored on.
• SourceSetRef? names the concrete declared source set or declared set result when several same-family source sets or set results are live or when one neighboring governing pattern must be cited to keep that identity unique. It may be omitted only when the concrete source set is unambiguous from the declared line.
• SearchSpaceRef points to one declared [A.19](/generated/patterns/A.19) CharacteristicSpace in the search-side position.
• OutcomeSpaceRef points to one declared [A.19](/generated/patterns/A.19) CharacteristicSpace in the outcome-side position.
• SpaceRefRelationKind states how those two refs relate. In ordinary use, the token is either sameDeclaredSpaceAs or distinctDeclaredSpaceFrom.
• SourceToOutcomeRelation is one controlled declaration slot. State at least direction, mode, and carrier.
• DistortionPosture is one controlled declaration slot with one primary posture token plus optional clarifying note. In this slice, lawful posture tokens include transparent-for-current-use, lossy-bridge, metric/model-dependent, transition-dependent, uncertainty-bearing, learned/adaptive, and unstable-under-refresh.
• SourceSetComposition, DerivedViewKind, and related ...Kind values remain declaration fields or controlled field values unless some governing pattern explicitly promotes them; they are not automatically independent heads merely because their names end with Kind.

This is an [A.6.5](/generated/patterns/A.6.5) / [A.6.P](/generated/patterns/A.6.P) move: SearchSpaceRef and OutcomeSpaceRef are ref-typed slot contents, while SpaceRefRelationKind is the explicit RelationKind token that governs how those two ref positions are read together.

#A.19.SOURCE-SET-SPACE-SUBSTRATE:4.3 - Substrate declaration laws (SS-0..SS-7)

SS-0 - One substrate line, one explicit stack. Treat a line as declared substrate only if one recoverable source-set basis, two recoverable space refs, one explicit ref-to-ref relation kind, one explicit source-to-outcome relation, and one explicit posture are present together.

SS-1 - Ref typing is preserved. SearchSpaceRef and OutcomeSpaceRef must resolve to declared A.19 CharacteristicSpace. They do not become parallel space kinds, slot aliases, or role claims.

SS-2 - Source-set recoverability is mandatory. The reader must be able to recover not only the source-set family but, when several same-family source sets or set results are simultaneously live, the concrete declared source set or set result through SourceSetRef? or one cited neighboring governing pattern that uniquely identifies it.

SS-3 - Relation requirement must be explicit. SourceToOutcomeRelation is conforming only when direction, mode, and carrier are explicit enough to tell what is related to what, through which carrier/relation mode, and through which declared interpretive qualifier.

SS-4 - Posture honesty is mandatory. DistortionPosture must say whether the line is transparent for current use or qualified by loss, metric/model dependence, transition dependence, uncertainty, learning/adaptation, or instability under refresh. The line may not hide qualification in atmospheric prose.

SS-5 - Conditional and qualifier fields stay subordinate. SourceSetComposition, DerivedViewKind, BasePaletteRef, OutcomeMapRef, SpaceMetricRef, TransitionRelationRef, and BridgeDistortionNote may clarify the substrate, but they do not replace the core stack and do not become mandatory everywhere.

SS-6 - Publication and policy stay outside. Publication metadata, shortlist identity, live-pool policy, and enactment policy remain neighboring decisions. A substrate line may feed them, but it does not decide them.

SS-7 - Admission is fail-closed. If the source set cannot be recovered, either space ref is unresolved, SpaceRefRelationKind cannot be chosen honestly, relation direction, mode, or carrier remains vague, or posture remains unclassified, then the line is not yet a declared substrate. Keep it as a working gloss or move it to the governing pattern that can close the missing requirement.

#A.19.SOURCE-SET-SPACE-SUBSTRATE:4.4 - Profiles

Use one of these ordinary profiles:

• Shared-space profile. SearchSpaceRef and OutcomeSpaceRef both resolve to the same declared CharacteristicSpace, and SpaceRefRelationKind = sameDeclaredSpaceAs.
• Cross-space profile. SearchSpaceRef and OutcomeSpaceRef resolve to two distinct declared CharacteristicSpace declarations, and SpaceRefRelationKind = distinctDeclaredSpaceFrom.
• Derived-source supplement. If the visible source set is one derived tradition, front, or palette view, keep DerivedViewKind and BasePaletteRef explicit so the derived view does not silently become the default meaning of the base palette or source set.

#A.19.SOURCE-SET-SPACE-SUBSTRATE:4.5 - Operational declaration sequence (fail-closed)

When declaring one substrate-bearing line, proceed in this order:

0. Entry test. Confirm that the line really needs source-set plus search/outcome-space plus relation/posture discipline. If it only needs CharacteristicSpace typing, use A.19. If it only needs publication or policy, apply the governing pattern that carries that publication or policy question.
1. Recover the active source set. State SourceSetFamily. If several same-family source sets or set results are simultaneously live, fill SourceSetRef? or cite the neighboring governing pattern that makes that identity unique.
2. Recover the space refs. Point SearchSpaceRef and OutcomeSpaceRef to already-declared CharacteristicSpace.
3. Choose the ref-to-ref relation kind. Declare sameDeclaredSpaceAs only when both refs truly resolve to one declared space. Declare distinctDeclaredSpaceFrom only when they truly resolve to two distinct declared spaces. Do not leave this to reader inference.
4. State the source-to-outcome relation. Give direction, mode, and carrier explicitly. If one named OutcomeMapRef or another declared interpretive qualifier carries the relation, cite that qualifier explicitly. If not, state the carrier directly in prose.
5. State the posture. Declare whether the line is transparent for current use or qualified by loss, metric/model dependence, transition dependence, uncertainty, learning/adaptation, or instability under refresh.
6. Add only the fields that are really doing work. Add composition, derived-view, base-palette, metric, transition, or bridge qualifiers only when the current case actually depends on them.
7. Run the boundary check. If the line starts deciding publication metadata, shortlist identity, live candidate policy, enactment policy, or interpretive-view organization, stop and apply the pattern that governs that question.

Fail-closed rule. Do not treat the line as declared substrate if any of steps 1-5 remains unresolved. Incomplete recovery is a real defect here, not one stylistic omission.

#A.19.SOURCE-SET-SPACE-SUBSTRATE:4.6 - Canonical rewrite forms

When the line is ready, it should be possible to rewrite it into one of these minimal forms.

Shared-space form

SourceSetFamily      = ...
SourceSetRef?       = ...
SearchSpaceRef         = DeclaredCharacteristicSpace@...
OutcomeSpaceRef        = DeclaredCharacteristicSpace@...
SpaceRefRelationKind   = sameDeclaredSpaceAs
SourceToOutcomeRelation= <direction, mode, carrier>
DistortionPosture      = <posture token; optional note>

Cross-space form

SourceSetFamily      = ...
SourceSetRef?       = ...
SearchSpaceRef         = SearchCharacteristicSpace@...
OutcomeSpaceRef        = OutcomeCharacteristicSpace@...
SpaceRefRelationKind   = distinctDeclaredSpaceFrom
SourceToOutcomeRelation= <direction, mode, carrier>
DistortionPosture      = <posture token; optional note>

If neither rewrite form can be completed honestly, the line is not yet publishable as substrate-bearing text.

#A.19.SOURCE-SET-SPACE-SUBSTRATE:4.7 - Conditional fields stay conditional

Use SourceSetComposition only when the line genuinely consumes several declared source sets.

When composition is active:

• SourceSetFamily still names the primary family the line is anchored on;
• SourceSetComposition names the additional declared source-set families or the explicit composed-source posture that widens that primary family;
• the composition field does not replace the primary family, and it does not silently retitle the whole line as one different source kind.

Use DerivedViewKind only when one derived view is materially active and the reader must be able to recover that derivation.

Use BasePaletteRef only when a derived tradition or palette view would otherwise hide the recoverable base palette.

#A.19.SOURCE-SET-SPACE-SUBSTRATE:4.8 - Qualifier refs stay substrate-side

OutcomeMapRef, SpaceMetricRef, TransitionRelationRef, and BridgeDistortionNote are admitted as substrate-side qualifier refs.

Use them when:

• one OutcomeMapRef or named declared map ref really disciplines the source-to-outcome relation;
• one metric really disciplines spread, neighborhood, or comparison claims;
• one TransitionRelationRef really disciplines dynamic coupling or transfer;
• or one bridge-loss note is the relevant reason the relation is qualified.

Do not make those interpretive qualifiers the semantic center of the substrate. They help explain the relation; they do not replace the line made explicit by SourceSetFamily, SourceSetRef?, SearchSpaceRef, OutcomeSpaceRef, and the declared relation/posture pair.

Qualifier semantics are first declared on the substrate side. Later interpretive views may reuse those qualifiers, but they do not become the place where the qualifier is first invented or materially changed.

#A.19.SOURCE-SET-SPACE-SUBSTRATE:4.9 - Descriptor maps and distance definitions dock here, but do not replace the space refs

When a neighboring line already uses DescriptorMapRef or DistanceDefRef, dock it explicitly:

• DescriptorMapRef may realize or qualify the search-side or outcome-side representation requirement, as the current line requires;
• DistanceDefRef may realize or qualify the metric requirement over that representation on either side, as the current line requires;
• but neither one replaces SearchSpaceRef or OutcomeSpaceRef;
• and CharacteristicSpace remains a different kind from DescriptorMap.

Use this docking rule whenever a reader could otherwise mistake one local representation layer for the whole search-side or outcome-side space reference.

#A.19.SOURCE-SET-SPACE-SUBSTRATE:4.10 - Publication and shipping remain downstream consumers

G.5 and G.10 may carry metadata such as SelectorOutcomeKind, SetResultFamily, SourceSetFamily, SourceSetComposition, DerivedViewKind, and BasePaletteRef when one selected or shipped result is being published.

That does not mean G.5 or G.10 defines the substrate.

Read the boundary this way:

• this pattern defines the substrate that later publication must preserve;
• G.5 publishes selector-facing outcome metadata;
• G.10 ships publication metadata and pins;
• neither one redefines the search-side reference, the outcome-side reference, or the source-to-outcome relation.

#A.19.SOURCE-SET-SPACE-SUBSTRATE:4.11 - Ordinary and heavier use

For ordinary use, one short declaration block is enough:

• one SourceSetFamily;
• SourceSetRef? when family-level naming alone would be ambiguous;
• one SearchSpaceRef;
• one OutcomeSpaceRef;
• one explicit SpaceRefRelationKind;
• one explicit relation line;
• one explicit posture line.

Use the heavier stack only when one of these is true:

• several declared source sets are genuinely composed;
• one derived view must stay recoverable;
• one interpretive qualifier is materially active;
• one descriptor-map or distance-definition docking clause is needed to prevent collapse;
• or the reader would otherwise mistake publication metadata for substrate semantics.

#A.19.SOURCE-SET-SPACE-SUBSTRATE:4.12 - Operator kit: choose, declare, self-check, apply governing neighbor

Use this compact kit whenever the task is practical declaration rather than one more explanatory paragraph.

Use this minimal worksheet when drafting or repairing one substrate line:

SourceSetFamily       = ...
SourceSetRef?        = ...
SearchSpaceRef          = ...
OutcomeSpaceRef         = ...
SpaceRefRelationKind    = sameDeclaredSpaceAs | distinctDeclaredSpaceFrom
SourceToOutcomeRelation = <direction, mode, carrier>
DistortionPosture       = <token; optional note>
Optional qualifiers       = <only those actually active>

Run this self-check before you leave the line:

• if the worksheet cannot be filled without one hidden assumption, the declaration is not ready yet;
• if the next needed prose is mainly "how should the reader inspect this substrate?", continue in A.19.DECLARED-SUBSTRATE-INTERPRETIVE-VIEW;
• if the next needed prose is "what gets published, shipped, retained, or enacted?", apply [G.5](/generated/patterns/G.5), [G.10](/generated/patterns/G.10), [C.19](/generated/patterns/C.19), or [C.24](/generated/patterns/C.24);
• if the current line changes because one neighbor wants different naming, glossing, or repair vocabulary, keep the substrate declaration here and let [F.18](/generated/patterns/F.18), [A.0](/generated/patterns/A.0), or [A.6.P](/generated/patterns/A.6.P) handle that neighboring requirement explicitly.

#A.19.SOURCE-SET-SPACE-SUBSTRATE:4.13 - Using the substrate with neighboring patterns

Once one substrate line is declared, use neighboring patterns in this order:

• Use A.19.DECLARED-SUBSTRATE-INTERPRETIVE-VIEW when the next requirement is interpretive help over the same substrate. The interpretive view may foreground the line, but it does not become the ontology.
• Use G.2 when that interpretation becomes palette-first, tradition-facing atlas work. Keep the base palette and the cited substrate recoverable while doing it.
• Use A.6.P when one passage collapses source set, space ref, interpretive view, atlas view, or map/ref wording into one umbrella word. Repair the wording back to the substrate declaration before adding more theory.
• Use F.18 when the problem is label choice or naming-side comparison around this stack. Naming notes may explain why one head is better named; they do not settle the substrate relation.
• Use A.0 when the task is cold-reader glossing of these tokens. Glosses help recognition; they do not replace the declaration block.

If a neighboring passage would change the source-to-outcome relation or the distortion posture, reopen this pattern first. Neighboring text may reuse the substrate, but it may not silently rewrite it.

#A.19.SOURCE-SET-SPACE-SUBSTRATE:5 - Archetypal Grounding

#A.19.SOURCE-SET-SPACE-SUBSTRATE:5.1 - System

Tell. One QD line keeps saying that one archive is both the search-side role and the evaluation basis. Downstream readers need to see that the same declared CharacteristicSpace can still occupy two different role positions without turning the archive or the descriptor layer into the space itself.

Show.

SourceSetFamily       = Archive
SearchSpaceRef          = BehaviorCharacteristicSpace@ed=12
OutcomeSpaceRef         = BehaviorCharacteristicSpace@ed=12
SpaceRefRelationKind    = sameDeclaredSpaceAs
SourceToOutcomeRelation = archive-retained candidates are navigated and judged
                          for local coverage gain in the same declared behavior
                          space
DistortionPosture       = metric/model-dependent; descriptor realization and
                          neighborhood metric qualifier are active
DescriptorMapRef        = QDDescriptorMap@ed=9
DistanceDefRef          = ArchiveNeighborhoodDistance@ed=4
SpaceMetricRef          = ArchiveNeighborhoodMetric@ed=4

Cash-out. This line now says three distinct things cleanly: the active source set is one archive, both role-refs resolve to the same declared CharacteristicSpace, and the DescriptorMapRef plus DistanceDefRef are only interpretive layers over that shared space reference. A downstream selection or archive-maintenance discussion can reuse this line without pretending the archive itself is the space.

#A.19.SOURCE-SET-SPACE-SUBSTRATE:5.2 - Episteme

Tell. One synthesis line presents one derived tradition front and then starts speaking as if the visible front were the default meaning of the whole palette.

Show.

SourceSetFamily       = Front
DerivedViewKind         = TraditionFront
BasePaletteRef          = SoTAPaletteDescriptionId
SearchSpaceRef          = TraditionComparisonSpace@ed=3
OutcomeSpaceRef         = AdoptionOutcomeSpace@ed=2
SpaceRefRelationKind    = distinctDeclaredSpaceFrom
SourceToOutcomeRelation = the visible tradition front is one derived reading
                          over the base palette and is compared against the
                          declared adoption outcome space through one explicit
                          cross-tradition outcome-bearing line
DistortionPosture       = lossy-bridge; derived-view selection and bridge-loss
                          notes must stay visible
BridgeDistortionNote    = CrossTraditionComparisonLossNote@ed=1

Cash-out. The visible front stays a derived view over the palette, the base palette stays recoverable, and the outcome-side evaluation line stays explicit. A later interpretive view or atlas view may reorganize this story, but it may not silently change the declared source-to-outcome relation or erase the bridge-loss warning.

#A.19.SOURCE-SET-SPACE-SUBSTRATE:5.3 - Boundary anti-case

Tell. One note says only that "the shortlist front is the published result for the current selector result" and names no source-to-outcome relation, no search-side space, no outcome-side space, and no posture.

Show. This is not a substrate declaration. It is publication metadata over one already-selected set.

Cash-out. Apply G.5 or G.10 to that note. Do not pad it with pseudo-substrate words just to make it look deeper than it is.

#A.19.SOURCE-SET-SPACE-SUBSTRATE:5.4 - Use-situation spread

Use the pattern this way across different working situations:

#A.19.SOURCE-SET-SPACE-SUBSTRATE:6 - Bias-Annotation

• Gov bias. The pattern prefers explicit declaration over convenient shorthand.
• Arch bias. The pattern keeps substrate, interpretive view, and publication consumers separated even when one merged story would read more smoothly.
• Prag bias. The pattern prefers a short explicit substrate declaration that can be reused across search, synthesis, and publication-adjacent lines.
• SoTA bias. The pattern assumes current QD and OEE work often uses learned, adaptive, unstructured, or uncertainty-bearing spaces and therefore resists premature geometric closure.

#A.19.SOURCE-SET-SPACE-SUBSTRATE:7 - Conformance Checklist

Treat a line as conforming only if every gate below passes.

#A.19.SOURCE-SET-SPACE-SUBSTRATE:8 - Common Anti-Patterns and How to Avoid Them

#A.19.SOURCE-SET-SPACE-SUBSTRATE:9 - Consequences

Benefits

• Readers can see what the line is acting on, what spaces it distinguishes, what relation is declared between the two space refs, and what outcome load it claims.
• A.19, C.18, G.5, and G.10 stay coordinated without collapsing into one layer.
• Heavier qualifiers such as declared map refs, metrics, transitions, and bridge-loss notes remain usable without being forced into every first slice.

Trade-offs

• The line must expose one explicit relation and one explicit posture instead of hiding them in umbrella prose.
• Some cases that used to look "simple" will expose real uncertainty or loss that now needs to be declared.
• Neighboring interpretive-view or publication patterns may need to be read as companions rather than assumed from local shorthand.

#A.19.SOURCE-SET-SPACE-SUBSTRATE:10 - Rationale

The pattern chooses a narrow but sturdy center of gravity.

A.19 already declares CharacteristicSpace. The missing load is not another free-floating space kind. It is the ref-position and relation stack that tells the reader:

• which declared source set is active;
• which declared space is named in the search-side position;
• which declared space is named in the outcome-side position;
• what SpaceRefRelationKind says about those two refs;
• and how much transparency, distortion, uncertainty, or error the line is honestly claiming.

That is why this pattern stops before interpretive views and before publication metadata. If it tried to say less, the load would collapse back into vague space or projection talk. If it tried to say more, it would start absorbing views, fronts, archives, shortlists, or shipping semantics that belong elsewhere.

#A.19.SOURCE-SET-SPACE-SUBSTRATE:11 - SoTA-Echoing

#A.19.SOURCE-SET-SPACE-SUBSTRATE:12 - Relations

• Builds on: A.19, A.17, A.18.
• Coordinates with: C.18, C.19, G.5, G.10, A.19.DECLARED-SUBSTRATE-INTERPRETIVE-VIEW, A.6.P, A.0.
• Specialized by: A.19.DECLARED-SUBSTRATE-INTERPRETIVE-VIEW and later interpretive-view or atlas specializations when one line needs derived interpretation over an already-declared substrate.
• Does not replace: selector outcome publication, shipping metadata, live pool policy, or enactment planning.

#A.19.SOURCE-SET-SPACE-SUBSTRATE:End

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