SoTA Pack Shipping (pack-boundary owner; SoTA-Pack(Core))
About this pattern
This is a generated FPF pattern page projected from the published FPF source. It is canonical FPF content for this ID; it is not a fpf-memory product feature page.
How to use this pattern
Read the ID, status, type, and normativity first. Use the content for exact wording, the relations for adjacent concepts, and citations to keep active work grounded without pasting the whole specification.
Tag: Architectural pattern (conceptual; notation‑independent; pack‑boundary owner)
Stage: release‑time composition and publication; edition‑aware; GateCrossing‑gated via E.18 CrossingBundle (and the relevant GateCrossing harness patterns).
Builds on: G.Core (Part‑G core invariants and routing); upstream pack/kit owners as cited artefacts (not redefined here).
Owns (scope boundary): shipping of Part‑G outputs as a pack (SoTA‑Pack(Core)), including the pack‑level publication kit: (i) selector‑facing selection/parity roster, (ii) PathId/PathSlice citation surface, (iii) telemetry pins for refresh planning, and (iv) optional interop ingestion as citation‑only notes.
Does not own: contract surfaces (CN‑Spec, CG‑Spec), CHR/CAL semantics, selection semantics, evidence semantics, bridge calibration semantics, refresh orchestration (these remain with their owners and are cited).
Part G produces many kit‑owned and suite‑owned artefacts (harvest packs, CHR/CAL packs, evidence graphs, bridge calibration artefacts, log bundles, parity reports). Without an explicit pack‑boundary owner, “shipping” tends to become:
Keywords
- shipping
- SoTA-Pack(Core)
- pack-boundary owner
- selector-ready publication surface
- AuditPins
- MOOManifest
- PortfolioRosterId
- UTS publication
- PathId/PathSliceId
- CrossingBundle
- edition pins
- telemetry pins
- RSCR wiring
- parity pins
- notation-independent pack
- no semantic respecification.
Relations
Content
Problem frame — Shipping without smuggling semantics
Part G produces many kit‑owned and suite‑owned artefacts (harvest packs, CHR/CAL packs, evidence graphs, bridge calibration artefacts, log bundles, parity reports). Without an explicit pack‑boundary owner, “shipping” tends to become:
- an ad‑hoc folder/export ritual (tool‑locked, not citable), or
- a silent re‑specification layer (shipping accidentally redefines legality, defaults, or selection semantics), or
- a brittle hand‑off that cannot support RSCR/refresh (no actionable pins/editions/policies attached).
G.10 fixes the pack boundary: it defines the single, normative shipping surface for Part‑G outputs — SoTA‑Pack(Core) — and a minimal choreography for making shipped artefacts selector‑ready and audit‑citable, while delegating all Part‑G‑wide invariants to G.Core (routing/delegation, not restatement).
Problem — Why naive shipping breaks reuse, legality, and refresh
Naive shipping fails (conceptually) when any of the following occurs:
- Format-as-contract. A concrete export format is treated as “the pack,” turning a tool choice into a semantic authority.
- Editionless hand‑offs. Shipped artefacts omit the edition/policy pins required to replay or compare outcomes, so parity and RSCR become non‑actionable.
- Pack smuggles semantics. Shipping reintroduces “convenience” rules (hidden scalarisation, competing defaults, private gate decisions), fragmenting the contract surface.
- Invisible crossings. Cross‑context/plane reuse is present, but the pack does not expose the crossing bundles and penalty policy pins needed for audit and refresh planning.
- No method‑of‑obtaining‑output disclosure. Consumers receive outcomes without a minimal, citable trail of which mechanisms/policies/editions produced them.
- Refresh orphaning. Telemetry and decay signals exist, but the shipped artefact provides no stable scope keys (
PathId/PathSliceId) and no payload pins for RSCR triggers.
Forces
Solution — SoTA‑Pack(Core) as the shipping object and publication kit
G.10 defines a pack‑owned shipping surface: a notation‑independent object that cites all upstream artefacts by stable ids/refs and exposes the minimum pins required to (a) consume the result via selection, (b) audit it via path citations and crossing bundles, and (c) refresh it via typed RSCR triggers.
G.Core linkage (normative)
Builds on: G.Core (Part‑G core invariants; single‑owner routing)
GCoreLinkageManifest (G.10) (normative; expands per G.Core:4.2; Nil‑elision applies)
Effective obligations/pins/triggers are computed as union(expand(sets), explicit deltas) under Nil‑elision.
-
CoreConformanceProfileIds:= {GCoreConformanceProfileId.PartG.AuthoringBase,GCoreConformanceProfileId.PartG.TriStateGuard,GCoreConformanceProfileId.PartG.UTSWhenPublicIdsMinted,GCoreConformanceProfileId.PartG.ShippingBoundary} -
RSCRTriggerSetIds:= {GCoreTriggerSetId.RefreshOrchestration} (payload pins:PackId(UTS),publicationScopeId,CNSpecRef.edition,CGSpecRef.edition,PlanItemRefs := SlotFillingsPlanItemRef[],AuditPins,UTSRowId[],PathId/PathSliceId, crossing policy pins,TelemetryPinIds, relevant upstream artefact ids) -
DefaultsConsumed:= {DefaultId.PortfolioMode,DefaultId.DominanceRegime,DefaultId.GammaFoldForR_eff} (Owners are routed viaG.Core.DefaultOwnershipIndexand are not restated here.) -
CorePinSetIds:= {GCorePinSetId.PartG.AuthoringMinimal,GCorePinSetId.PartG.CrossingVisibilityPins} -
CorePinsRequired(pattern delta; pin names only; id‑valued unless noted) := {PackId(UTS),publicationScopeId,contextSliceId?,PlanItemRefs := SlotFillingsPlanItemRef[]?(WorkPlanning planned baseline refs),AuditPins(pack‑level pin bundle: edition pins (only on…Ref.edition), policy‑ids, UTS/Path pins; ids only),UTSRowId[],PathId[]?,PathSliceId[]?,CrossingBundleIds := CrossingBundleId[]?,TelemetryPinIds := TelemetryPinId[]?,PortfolioRosterId?,MOOManifestId?(method‑of‑obtaining‑output disclosure; conceptual object id) } (Optional pins fromCrossingVisibilityPinsMAY be strengthened to unconditional by listing them above;G.10typically strengthensUTSRowId[]and path/crossing bundles when the pack is publicly shipped.) -
TriggerAliasMapRef:=∅(no local trigger tokens in Phase‑2)
Mode‑specific definition pins. Any additional pins required for QD/OEE/interop shipping are introduced only by
GPatternExtensionblocks inG.10:4.6(never smuggled into the core linkage).
SoTA‑Pack(Core) object model (normative; notation‑independent)
SoTA‑Pack(Core) is a shipment object (a pack, not a kit and not a suite) that cites upstream artefacts and exposes pack‑level pins required for downstream use.
Portfolio roster (normative; pack‑owned; owner‑delegating)
PortfolioRosterId identifies the selector‑facing pack roster token. The corresponding PortfolioRoster@Context is one citation-and-binding roster record inside the shipped publication surface, not a Surface or SurfaceKind value:
it MUST NOT redefine selection / selected-set semantics (owned by G.5) or parity semantics (owned by G.9).
Mode‑specific definition pins (QD/OEE/interop) are introduced only via G.10:Ext.* blocks.
Presence rule: PortfolioRosterId MAY be omitted only when the shipped pack is inputs‑only
(e.g., shipping CHR/CAL/evidence without any selector‑consumable selected-set/shortlist output).
The selectorOutcomeKind, setSurfaceKind, handoffKind, sourceSurfaceKind, sourceSurfaceComposition, derivedViewKind, basePaletteRef, lensId, and shortlistId fields in this roster are payload metadata fields or refs inside the shipped publication surface. They do not define new Part-E SurfaceKind values and they do not let G.10 re-own G.5, C.18, C.19, or G.2 semantics.
Interpretation constraints (normative by delegation). Any universal invariants governing (i) contract‑surface ownership, (ii) crossing visibility and penalty routing, (iii) tri‑state guards, (iv) set‑return semantics, (v) P2W split, (vi) defaults, and (vii) RSCR trigger typing are not restated here and are enforced via G.Core routing (see CC‑G10‑CoreRef).
Shipping choreography (normative; owner‑delegating)
G.10 prescribes a minimal, owner‑delegating sequence for composing a shipped pack:
- S‑1 — Gather & pin. Collect upstream artefact ids and verify the required pins implied by the linkage manifest (edition pins, policy pins, UTS/Path pins).
- S‑2 — Compose
SoTA‑Pack(Core)+ MOO disclosure. Assemble the pack object and attach aMOOManifestthat lists the referenced mechanisms/policies/editions that produced the shipped outcomes (ids only; semantics stay with owners). - S‑3 — Publish selection/parity roster (selector‑facing). Produce a selector‑readable
PortfolioRosterIdwith the parity/definition pins required for reproducibility; do not mandate formats. - S‑4 — Anchor and publish path citations. Ensure A.10 anchors exist and publish/record
PathId/PathSliceIdcitations required for downstream explainability (e.g.,C.23/H4) and maturity rung changes. - S‑5 — Expose CrossingBundle. For each GateCrossing relevant to the shipped artefacts, expose the required
CrossingBundlereferences (fail fast on missing or non‑conformant bundles when required). - S‑6 — Emit telemetry pins for refresh planning. Whenever illumination increases or archive/OEE pin state changes, emit PathSlice‑keyed telemetry with policy‑id and the active
…Ref.editionpins (and QDEmitterPolicyRef/InsertionPolicyRefwhen applicable). - S‑7 — Publish to UTS (twin labels). Mint/refresh UTS Name Cards needed to cite the pack and shipped heads (Tech/Plain twins when required); cross‑Context identity travels only via Bridges with CL and loss notes.
- S‑8 — Optional: ingest interop surface. If
G.13interop is in use, ingest/citeInteropSurface@Contextas annotation-only notes, pinning external index editions; do not redefine interop semantics.
Interfaces & hooks (selector‑ and audit‑facing)
Surfaces remain conceptual per E.5.2; RO‑Crate/ORKG/OpenAlex mappings belong to Annex/Interop and do not affect Core conformance.
Note. Any concrete serialisation/export is not part of this interface set. Serialisation belongs to interop/annex ownership and must not become a semantic authority.
Consequence of ownership (normative boundary statement)
G.10 is the single owner of “shipping” in Part G (by delegation to CC‑GCORE‑SKP‑1).
Other G.x patterns may produce artefacts that are shipped, but they must not embed shipping obligations; they cite G.10 shipping surfaces instead.
Extensions (pattern‑scoped; non‑core)
All method‑/generator‑/interop‑specific shipping extension declarations live here as GPatternExtension blocks.
GPatternExtension — G.10:Ext.QDArchiveShippingPins
PatternScopeId: G.10:Ext.QDArchiveShippingPins
GPatternExtensionId: QDArchiveShippingPins
GPatternExtensionKind: MethodSpecific
SemanticOwnerPatternId: C.18
Uses: {C.18, G.5, G.8, G.11}
⊑/⊑⁺: ∅
RequiredPins/EditionPins/PolicyPins (minimum):
DescriptorMapRef.editionDistanceDefRef.editionDHCMethodRef.edition?DHCMethodSpecRef.edition?EmitterPolicyRef(policy‑id / ref)InsertionPolicyRef(policy‑id / ref)CharacteristicSpaceRef(id/ref; iff archive partitioning is declared)CharacteristicSpaceRef.edition?(iff partitioning depends on an editioned space definition)PathSliceId[](to bind telemetry/refresh scope when archive behaviour is present)
RSCRTriggerSetIds: ∅ (covered by G.10 core linkage via GCoreTriggerSetId.RefreshOrchestration)
Notes (shipping-pin discipline):
- This block never redefines archive semantics; it only states which pins must be present in the shipped pack when QD archive fields are present.
GPatternExtension — G.10:Ext.OEEShippingPins
PatternScopeId: G.10:Ext.OEEShippingPins
GPatternExtensionId: OEEShippingPins
GPatternExtensionKind: GeneratorSpecific
SemanticOwnerPatternId: G.5
Uses: {G.5, G.11}
⊑/⊑⁺: ∅
RequiredPins/EditionPins/PolicyPins (minimum):
TransferRulesRef.editionEnvironmentValidityRegion?(id/ref; iff an explicit region is declared as part of generator-family support)PathSliceId[](scope key for refreshable generator telemetry when present)
RSCRTriggerSetIds: ∅ (covered by the core trigger set)
Notes (shipping-pin discipline):
- “Open‑endedness” semantics remain owner‑defined; the pack only carries the pins required to make the shipped claim replayable/auditable.
GPatternExtension — G.10:Ext.InteropCitation
PatternScopeId: G.10:Ext.InteropCitation
GPatternExtensionId: InteropCitation
GPatternExtensionKind: InteropSpecific
SemanticOwnerPatternId: G.13
Uses: {G.13}
⊑/⊑⁺: ∅
RequiredPins/EditionPins/PolicyPins (minimum):
InteropSurfaceIdExternalIndexRef.editionClaimMapperRef.editionPlaneMapRef.edition?MappingPolicyRef
RSCRTriggerSetIds: ∅ (covered by the core trigger set)
Notes (shipping-pin discipline):
- This block only records that an interop surface contributed to the shipped pack’s provenance; it does not redefine any crosswalk semantics.
Published surfaces must ship kind, source, derivation, lens, and shortlist token
- Published surfaces should carry the selector outcome kind and, when applicable, the set-surface kind or handoff kind, plus the subject kind, source surface kind, and relevant declared surface pins.
- These are publication payload metadata fields inside
SoTA-Pack(Core), not new Part-ESurfaceKindvalues. - Good publication fields include
selectorOutcomeKind,setSurfaceKind,handoffKind,subjectKind,sourceSurfaceKind,sourceSurfaceComposition,dominanceRegime,lensId,shortlistId, and any declared archive or promotion-policy ids that the reader needs to interpret the visible set. - Those payload fields should use controlled tokens, cited ids, or already-declared head labels rather than shipping-local prose values.
- When the visible surface or the shortlisted source is one derived tradition view, also publish the derivation explicitly.
- Useful additional fields there include
derivedViewKind,basePaletteRef, and the declaredqIdor reachability rule id that disciplined that derivation. portfolioModemay remain as one support field about selector operation, but it should not stand in for the public set label.- A published surface should mirror semantics that are already declared in the governing palette/front/archive/shortlist language.
- It should not redefine that semantics locally.
- When one shipped surface still needs a plain-language label, use the declared set-surface kind and source surface rather than falling back to
portfolioMode.
Worked publication slice
- If the visible surface is one tradition front under the declared
Q, publishselectorOutcomeKind=SetSurfaceOutcome,setSurfaceKind=Front,sourceSurfaceKind=Front,derivedViewKind=TraditionFront, and keepbasePaletteRef=SoTAPaletteDescriptionIdrecoverable instead of pretending that the palette itself already was that front. - If one shortlist is emitted from that derived tradition front, publish
selectorOutcomeKind=SetSurfaceOutcome,setSurfaceKind=Shortlist,sourceSurfaceKind=Front,derivedViewKind=TraditionFront,basePaletteRef=SoTAPaletteDescriptionId, and the namedlensIdtogether. - If that same shortlisted surface is emitted as one stable public object, also publish
shortlistId=<...>and keep it recoverable that the token names that shortlist rather than replacing it. - If one retained tradition archive view is shown, publish
selectorOutcomeKind=SetSurfaceOutcome,setSurfaceKind=Archive,sourceSurfaceKind=Archive,derivedViewKind=TraditionArchive, and keep the samebasePaletteRefrecoverable. - If the shortlist is later ordered, publish
setSurfaceKind=RankedShortlistand keep the declared source surface visible. - Do not publish
setSurfaceKind=ChoiceSetunless the shipped object is explicitly one mathematical analysis artifact rather than the public selected surface. - Do not publish
sourceSurfaceKind=TraditionPalettealone when the visible object is already one derived tradition view; readers need to know which view is on the surface and which base palette it depends on. - Do not publish
TraditionFrontorTraditionArchiveas if they were the default meaning ofTradition. - Do not ask
portfolioModeto tell the reader whether they are seeing one palette, one front, one archive, or one shortlist.
Consequences
Benefits
- A shipped result becomes selector‑ready and audit‑citable without turning file formats into a contract.
- Shipping is no longer a semantic “backdoor”: pack‑level semantics remain owner‑delegated.
- RSCR/refresh becomes operationally viable because pack‑level scope keys and payload pins are present.
Costs / trade‑offs
- Shipping becomes more explicit (more pins and explicit surfaces), which raises authoring overhead.
- If upstream owners fail to provide citable ids/pins,
G.10cannot paper over the gap; shipping will block or ship a visibly incomplete pack (depending on policy‑bound failure behaviour, routed via owners).
Bias‑Annotation (informative)
Lenses tested: Gov, Arch, Onto/Epist, Prag, Did.
- Format bias (Arch/Prag). Strong temptation to treat a popular export format as “the pack”.
Mitigation: keep Core surfaces conceptual (E.5.2); move serialisation recipes to Annex/Interop; keep conformance on semantics. - Centralisation bias (Gov). A single shipping owner can become a bottleneck.
Mitigation: keep shipping as one explicit owner burden, but push mode/method specifics into explicitG.10:Ext.*extension blocks and cite semantic owners. - Telemetry→dominance bias (Onto/Prag). Shipping pipelines often “promote” telemetry proxies (illumination/coverage) into ranking.
Mitigation: preserve the telemetry/order separation and require explicit CAL policy‑id for any promotion; record the policy‑id in audit pins/telemetry. - Interop authority bias (Onto/Epist). External indexes can silently override local legality/typing.
Mitigation:G.10‑6ingests interop only as cited notes (editions + mapping policy refs), never as a replacement contract surface.
Archetypal grounding (informative; post‑2015 method families)
World‑plane (benchmark shipping).
A CG‑Frame ships a selected set that includes a QD archive (e.g., MAP‑Elites‑class / CMA‑ME‑class families) and a generator family (e.g., POET‑class environment generation). The shipped SoTA‑Pack(Core) cites the CHR/CAL packs and records the QD/OEE extension-required pins through the extension blocks so that downstream parity and refresh can be scoped to the affected PathSliceIds rather than forcing a global rebuild.
Episteme‑plane (synthesis shipping). A CG‑Frame ships a pluralistic set of admissible methods gathered from post‑2015 literature streams (living review + synthesis pack). The shipped pack carries explicit contract‑surface refs, evidence path citations, and method‑of‑obtaining‑output disclosure; downstream selection uses set‑valued outcomes and can schedule refresh when the synthesis pack or key pins change.
Conformance checklist (CC‑G10)
This pattern inherits order/illumination, evidence, and bridge/penalty legality from the cited owners (not restated here). Shipping‑specific requirements:
Anti‑patterns and remedies
- AP‑1 Format‑as‑contract. Remedy: keep Core surfaces conceptual (E.5.2); move serialisation to Annex/Interop; enforce
CC‑G10.1. - AP‑2 Hidden edition drift. Remedy: require
…Ref.editionpins in AuditPins and treat edition changes as RSCR‑relevant via canonical trigger kinds. - AP‑3 “QD archive present” but missing definition pins. Remedy: enforce
CC‑G10.2and theG.10:Ext.QDArchiveShippingPinspin declarations. - AP‑4 Telemetry silently becomes dominance. Remedy: keep telemetry report‑only unless an explicit CAL policy promotes it; require policy‑id recorded (ties to
CC‑G10.3and MOO discipline). - AP‑5 No PathSlice key → refresh becomes global. Remedy: enforce PathSlice‑keyed telemetry and path citations (
G.10‑4,G.10‑5). - AP‑6 Cross‑Context reuse without visible routing. Remedy: require
CrossingBundleIds+ Bridge/CL policy pins; fail fast on missing/non‑conformant bundles (CC‑G10.7). - AP‑7 Interop ingestion rewrites semantics. Remedy: ingest interop as cited notes only; semantics remain in
G.13(G.10‑6,G.10:Ext.InteropCitation). - AP‑8 Derived-view collapse. Remedy: ship
sourceSurfaceKind,derivedViewKind,basePaletteRef, and the declaredQor reachability basis strongly enough that one derived tradition view cannot masquerade as the default palette meaning.
SoTA‑Echoing (post‑2015, for orientation)
- Research‑object packaging & provenance. Post‑2015 practice increasingly treats “release artefacts” as packages with explicit provenance, versions, and minimal replay pins (e.g., modern research‑object and RO‑Crate‑class approaches).
G.10mirrors the “package‑as‑citation‑surface” idea while keeping semantics owner‑delegated. - Reproducibility regimes in ML/AI. Contemporary reproducibility checklists, artifact evaluation/badging, and benchmark reporting norms motivate: explicit version pins, explicit method disclosure, and separating telemetry summaries from decision criteria unless policy‑promoted.
- Scholarly KG interoperability. ORKG/OpenAlex‑class ecosystems highlight the need to treat external mappings as interop notes with editions, not as replacement contract surfaces — matching the
G.10‑6andG.10:Ext.InteropCitationstance.
Relations
Builds on: G.Core; consumes/cites owner artefacts from G.2 (harvest pack), G.3 (CHR pack), G.4 (CAL pack), G.6 (EvidenceGraph), G.7 (bridge calibration), G.8 (SoS‑LOG bundle), G.9 (parity report), optional G.12 (dashboard slice), optional G.13 (interop surface).
Publishes to / used by: UTS (pack identity), selector‑facing consumers (via G.5), audit/assurance surfaces (SCR/RSCR), refresh orchestration (G.11).
Constrains: tooling exports are downstream; serialisation and repository integration are explicitly non‑normative here.