G.13:4 - Solution — Conceptual interop kit: registered sources, alignment cards, feature derivations, and RSCR‑wired telemetry

G.13:4.1 - G.Core linkage (normative)

Builds on: G.Core.

GCoreLinkageManifest (normative). (Canonical form, Nil‑elision, and Expansion rule are defined in G.Core.)

`GCoreLinkageManifest := ⟨ CoreConformanceProfileIds := { GCoreConformanceProfileId.PartG.AuthoringBase, GCoreConformanceProfileId.PartG.UTSWhenPublicIdsMinted, GCoreConformanceProfileId.PartG.ShippingBoundary }, RSCRTriggerSetIds := {GCoreTriggerSetId.SoTAHarvestSynthesis}, RSCRTriggerKindIds := {RSCRTriggerKindId.BaselineBindingEdit}, // delta: planned‑baseline linkage edits can be interop‑relevant

CorePinSetIds := { GCorePinSetId.PartG.AuthoringMinimal, GCorePinSetId.PartG.CrossingVisibilityPins },

CorePinsRequired := { // Interop pins (G.13‑specific; avoid duplicating GCorePinSetId.PartG.CrossingVisibilityPins) ExternalIndexRef.edition, ClaimMapperRef.edition?, MappingPolicyRef?, PlaneMapRef.edition?, ScaleEmbeddingSpecRef.edition?,

EvidenceGraphId?,
InteropSurfaceId?

},

DefaultsConsumed := {DefaultId.PortfolioMode, DefaultId.DominanceRegime} ⟩`

Payload‑pin note (informative). When emitting RSCR triggers for interop‑driven changes, payload pins should include the edited edition/policy identifiers, the impacted scope, and the applicable crossing‑visibility pins (per GCorePinSetId.PartG.CrossingVisibilityPins) when crossings/UTS/paths are involved.

G.13:4.2 - Interop kit objects & surfaces (pattern-governed; notation‑independent)

All objects below are conceptual. Any concrete serialisation belongs to Annex/Interop or tooling notes and is not normative for Part‑G conformance.

• ExternalIndexCard@Context — registration of an external source and its snapshot.

  Shape (conceptual): ⟨ ExternalIndexId, ProviderName?, ExternalIndexType, CoverageScope, Licence?, ExternalEdition, FreshnessWindow?, entityOfConcern := ⟨GroundingHolon, ReferencePlane⟩, Notes? ⟩

  Intent. Create a stable, citable “source card” so downstream artefacts can pin the card edition via ExternalIndexRef.edition, while the provider snapshot remains visible as ExternalEdition (do not echo provider snapshot ids into downstream cards; cite refs instead).

• ClaimMapperCard@Context — a conceptual “mapping recipe” that yields FPF‑native artefacts from an external source.

  Shape (conceptual): ⟨ MapperId, ExternalIndexId, MappingPolicyRef, Targets{ClaimSheet|BridgeHints|SoSFeatureSet|UTSProposals}, PlaneMapRef?, ScaleEmbeddingSpecRef?, EvidenceGraphId?, CSLCProofStubs? ⟩

  Notes.

  • This is not a shadow legality gate. It is an interop surface that cites governing definitions (A.19, G.0, G.3, G.4) and publishes the required pins for downstream audit/refresh.
  • When cross‑plane or cross‑context reuse is implicated, the alignment outputs must use the existing crossing bundles (see G.Core linkage).
  • Avoid “edition echo”: downstream artefacts cite ExternalIndexRef.edition and ClaimMapperRef.edition (and optional PlaneMapRef.edition / ScaleEmbeddingSpecRef.edition) rather than copying snapshot ids/editions as free fields.

• SoSFeatureTransform@Context — declares how external signals become CHR‑typed SoS features (for DHC/dashboard usage and/or SoS‑LOG rule evaluation).

  Shape (conceptual): ⟨ SoSFeatureTransformId, Inputs{ClaimSheetId[] | ExternalSignalsRef}, SoSFeatureSetId, FeatureTypingRefs{CharacteristicId/ScaleId/CoordinateId}, ReferencePlane, EvidenceGraphId?, PathSliceId[]?, ProofHooks? ⟩

  Notes.

  • The derivation records typing + provenance; comparator and legality definitions remain with the cited governing patterns. When features are used as DHC measurements, establish or reuse C.16 measurement results. Make the active C.21 DHCReplayBasis recoverable for every persisted, compared, aggregated, or published coordinate.

• ScaleEmbeddingSpec@Context — optional constraints for representation/space alignment used inside an alignment recipe.

  Shape (conceptual): ⟨ ScaleEmbeddingSpecId, IntendedUse, AllowedTransformFamily, RequiredPins{NormalizationMethodRef.edition?}, ProhibitedCoercions ⟩

  Design intent. Make any representation alignment explicitly constrained and edition‑pinned, instead of silently “creating a new scale”. LEX/UTS note (informative). ScaleEmbeddingSpec is a LEX head; when a public id is minted for a ScaleEmbeddingSpec, the corresponding UTS row must be published with twin labels (see G.Core / UTS profile).

• IndexTelemetryPin — an emitted refresh input that makes interop changes RSCR‑visible.

  Shape (conceptual; RSCR‑typed): ⟨ triggerKindId: RSCRTriggerKindId, scope: PathSliceId[] | PathId[] | PatternScopeId, payloadPins{ExternalIndexId, ExternalIndexRef.edition, ClaimMapperRef.edition?, MappingPolicyRef?, PlaneMapRef.edition?, ScaleEmbeddingSpecRef.edition?, PathId[]?, PathSliceId[]?, UTSRowId[]?, …} ⟩

  Publication. Emitted to G.11 as refresh input; recorded with canonical RSCRTriggerKindId causes.

• InteropSurface@Context — a selector-facing or dashboard-facing summary of what interop publications and records exist and how they are pinned.

  Shape (conceptual): ⟨ InteropSurfaceId, ExternalIndexId, ExternalIndexRef.edition, MapperId?, ClaimMapperRef.edition?, MappingPolicyRef?, SoSFeatureSetId?, EvidenceGraphId?, PathSliceId[]?, PlaneMapRef.edition?, ScaleEmbeddingSpecRef.edition?, UTSRowId[] ⟩

  Publication. Published to UTS with twin labels as applicable.

G.13:4.3 - Generation‑first interop flow (notation‑independent; governing-definition delegating)

1. Register source editions. Author ExternalIndexCard@Context for each external source/snapshot used for SoTA authoring, including ExternalEdition and the entityOfConcern plane anchor.

2. Author mapping recipes. Create ClaimMapperCard@Context describing which FPF artefacts are produced (ClaimSheets, BridgeHints, feature sets, UTS proposals), and which policies/specs constrain the mapping (policy refs + optional PlaneMapRef / ScaleEmbeddingSpecRef).

3. Produce FPF‑native inputs. Use the alignment recipe outputs as inputs to:

   • G.2 harvesting (ClaimSheets / operator & object inventories / candidate bridge hints),
   • G.3 CHR typing (when numeric signals are formalized as CHR characteristics/scales/coordinates),
   • G.4 acceptance/threshold policies (when a downstream decision requires explicit CAL policy rather than telemetry),
   • G.12 dashboards (when derived SoS features support DHC readings; measurement claims consume C.16 results with the C.21 replay basis required by their use).

4. Feed selection/parity/shipping without smuggling semantics.

   • G.5 consumes the produced artefacts under its own governing spec refs and returns its declared outcome, including the applicable set-result kind, narrowed handoff, abstain, or escalation result (selector semantics remain governed by G.5 + G.Core).
   • G.9 parity consumes pinned editions/windows and produces traceable parity reports.
   • G.10 shipping may include interop surfaces as cited publications or records; G.13 does not govern shipping.

5. Emit telemetry and refresh causes. On any change in external editions, alignment policies, plane maps, or embedding specs, emit:

   • a canonical RSCRTriggerKindId (per G.Core),
   • a scope (PathSliceId[] and/or PatternScopeId),
   • payload pins (editions/policies/UTS rows), enabling G.11 to plan slice‑scoped refresh.

G.13:4.4 - Interfaces — minimal I/O standard (conceptual; kit‑only)