Library / First Principles Framework (FPF) - Core Conceptual Specification
Jump to passage
In this reading

Link to current text

Published source confirmed at last check

Source changed 2026-10-03 17:24:51 UTC · snapshot created 2026-10-03 17:30:20 UTC · last check 2026-10-03 17:30:10 UTC

G.10:4 - Solution — SoTA‑Pack(Core) as the shipping object and publication kit

G.10 defines a pack-governed 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.10:4.1 - G.Core linkage (normative)

Builds on: G.Core (Part‑G core invariants; Default Governing Definition Index citation)

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 := ⟨WorkPlanRef, planLocalContentLocator⟩[], AuditPins, UTSRowId[], PathId/PathSliceId, crossing policy pins, TelemetryPinIds, relevant upstream artefact ids)

  • DefaultsConsumed := { DefaultId.PortfolioMode, DefaultId.DominanceRegime, DefaultId.GammaFoldForR_eff } (Governing definitions are resolved through G.Core.DefaultGoverningDefinitionIndex and 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 := ⟨WorkPlanRef, planLocalContentLocator⟩[]? (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 from CrossingVisibilityPins MAY be strengthened to unconditional by listing them above; G.10 typically strengthens UTSRowId[] and path/crossing bundles when the pack is publicly shipped.)

  • TriggerAliasMapRef := ∅ (canonical trigger ids are used directly)

Mode‑specific definition pins. Any additional pins required for QD/OEE/interop shipping are introduced only by GPatternExtension blocks in G.10:4.6 (never smuggled into the core linkage).

G.10:4.2 - 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.

SoTA‑Pack(Core) :=
⟨
  PackId(UTS),
  publicationScopeId,
  contextSliceId?,
  CG-FrameContext,
  entityOfConcern := ⟨GroundingHolon, ReferencePlane⟩,

  // Governing spec refs (refs + edition pins; semantics governed by their patterns)
  CNSpecRef := ⟨A.19 ref, CNSpecRef.edition⟩,
  CGSpecRef := ⟨G.0 ref,  CGSpecRef.edition⟩,

  // Selector-facing selection/parity roster token (conceptual; no formats mandated)
  PortfolioRosterId?,        // produced by `G.10‑1` as part of composition; may cite ε and the applicable pinned regime/mode refs

  // Cited payload packs/kits (ids only; semantics governed by the cited governing patterns)
  SoTAHarvestPackId?          // e.g., G.2 output id
  CHRPackId?                  // G.3 output id
  CALPackId?                  // G.4 output id
  EvidenceGraphId?            // G.6 output id
  BridgeMatrixId?             // G.2/G.7 cited id
  BridgeCalibrationTableId?   // G.7 output id
  SoSLOGBundleId?             // G.8 output id
  ParityReportId?             // G.9 output id
  DashboardSliceId?           // G.12 output id (optional)
  InteropSurfaceId?           // G.13 output id (optional)

  // Path citation surface (ids only; semantics governed by A.10/G.6)
  PathIds := PathId[]?,
  PathSliceIds := PathSliceId[]?,

  // Planned baseline + audit pins (P2W-aware; ids only)
  PlanItemRefs := ⟨WorkPlanRef, planLocalContentLocator⟩[]?,
  AuditPins := { id pins… },                 // editions only on `…Ref.edition`; includes policies, UTS/Path pins, crossing pins

  // Crossing visibility surface (per GateCrossing; ids only)
  CrossingBundleIds := CrossingBundleId[]?,

  // Telemetry hooks for refresh planning (ids only; PathSlice-keyed; policy-id pinned)
  TelemetryPinIds := TelemetryPinId[]?,

  // Method-of-obtaining-output (MOO) disclosure (conceptual; ids only)
  MOOManifestId?,

  Notes?
⟩

PlanItemRefs, when present, resolve the exact U.WorkPlan episteme and locate the baseline content inside it. For A.15.3 content, the locator uses that WorkPlan’s planItemDesignator and any needed rowDesignator; it gives the item or row no independent identity or edition. An ordinary A.15.2 baseline stays ordinary plan content when it reuses no declaration member. A changed plan must not silently replace the earlier reference carried by the shipped pack.

G.10:4.2.1 - Portfolio roster (normative; pack-governed; governing-definition delegating)

PortfolioRosterId identifies the selector‑facing pack roster token. The corresponding PortfolioRoster@Context is one citation-and-binding roster record inside the shipped publication form, not a publication face kind, publication form kind, interop publication form kind, or carrier kind: it MUST NOT redefine selection / selected-set semantics (governed by G.5) or parity semantics (governed by G.9). Mode‑specific definition pins (QD/OEE/interop) are introduced only via G.10:Ext.* blocks.

PortfolioRoster@Context :=
⟨
  PortfolioRosterId,
  PackId(UTS),
  CG-FrameContext,
  entityOfConcern,

  // Selector operation and default-resolution support
  portfolioMode?,
  dominanceRegime?,
  ε?,

  // Published selector outcome and set-result declaration (metadata fields, not local semantics)
  selectorOutcomeKind?,
  setResultFamily?,
  handoffKind?,
  subjectKind?,
  sourceSetFamily?,
  derivedViewKind?,
  sourceSetComposition?,
  basePaletteRef?,
  lensId?,
  shortlistId?,
  promotionPolicyRef?,
  retentionIntent?,

  // Selector-facing roster + provenance hooks (ids only)
  MethodFamilyRowRefs := MethodFamilyRowRef[]?,
  GeneratorFamilyRowRefs := GeneratorFamilyRowRef[]?,
  ParityReportId?,
  SCRId[]?, DRRId[]?,

  // Pin reuse: prefer referencing the enclosing pack’s AuditPins bundle
  AuditPins?,
  Notes?
⟩

The roster cites exact G.5 MethodFamilyRowRef = <MethodFamilyId, rowEdition> and GeneratorFamilyRowRef = <GeneratorFamilyId, rowEdition> values. A lineage id alone cannot replay the selected membership or grouping basis; each row ref resolves its immutable source edition. Shipping these references neither admits the members nor creates their grouping. Preserve the row’s G.5 local or public registry-identity contract. A visible project-local row is not automatically a public registry entry; intentional public registration adds S1/S1′ naming and UTS duties. G.10’s independently applicable pack-shipping requirements and E.24.PUB availability conditions still apply.

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, setResultFamily, handoffKind, sourceSetFamily, sourceSetComposition, derivedViewKind, basePaletteRef, lensId, and shortlistId fields in this roster are payload metadata fields or refs inside the shipped publication form. They do not define publication face kinds, publication form kinds, interop publication form kinds, or carrier kinds, and they do not let G.10 re-govern G.5, C.18, C.19, or G.2 semantics.

Interpretation constraints (normative by delegation). Any universal invariants governing (i) CN/CG spec-ref governing-definition assignment, (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 conformance (see CC‑G10‑CoreRef).

G.10:4.3 - Shipping choreography (normative; governing-definition delegating)

G.10 prescribes a minimal, governing-definition delegating sequence for composing a shipped pack:

  1. 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).
  2. S‑2 — Compose SoTA‑Pack(Core) + MOO disclosure. Assemble the pack object and attach a MOOManifest that lists the referenced methods, mechanisms, and policies used, at their exact editions, to obtain the shipped outcomes (ids only; semantics stay with governing definitions).
  3. S‑3 — Publish selection/parity roster (selector‑facing). Except when the inputs-only presence-rule exception in §4.2.1 is used, produce a selector‑readable PortfolioRosterId with the parity/definition pins required for reproducibility; do not mandate formats.
  4. S‑4 — Anchor and publish path citations. Ensure A.10 anchors exist and publish/record PathId/PathSliceId citations required for downstream explainability (e.g., the C.23 W2 AdmissibilityLedger) and maturity rung changes.
  5. S‑5 — Expose CrossingBundle. For each GateCrossing relevant to the shipped artefacts, expose the required CrossingBundle references (fail fast on missing or non‑conformant bundles when required).
  6. 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.edition pins (and QD EmitterPolicyRef/InsertionPolicyRef when applicable).
  7. 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); a claimed cross-context semantic correspondence cites its F.9 relation, separate bounded-use claim and reliance. G.7 calibration and loss notes remain evidence for that use, not identity or permission.
  8. S‑8 — Optional: ingest interop surface. If G.13 interop is in use, ingest/cite InteropSurface@Context as annotation-only notes, pinning external index editions; do not redefine interop semantics.

G.10:4.4 - Interfaces & hooks (selector‑ and audit‑facing)

IDInterface (conceptual)ConsumesProduces
G.10‑1Compose_SoTA_PackG.* outputs, ComparatorSet, Bridges, editions, SCR/DRR deltasSoTA‑Pack(Core) (UTS row + surfaces) + AuditPins (+ MOOManifestId?) (+ PortfolioRosterId?)
G.10‑2Publish_UTSPackId(UTS), UTSRowId[], deprecation/edition‑bump notesUTS rows/Name Cards for the pack and shipped heads (incl. twins when required)
G.10‑3Expose_CrossingHooksGateCrossings, lanes/planes/contextsCrossingBundle (E.18:CrossingBundle) per GateCrossing; fail on missing/non‑conformant bundles
G.10‑4Pack_MOOreferenced method/mechanism/policy/edition idsMOOManifestId (ids only; governing-definition delegating)
G.10‑5Emit_TelemetryPinsIllumination/archive/OEE eventsPathSlice‑keyed telemetry: policy‑id, …Ref.edition (+ QD/OEE pins when applicable)
G.10‑6Publish_PathCitationsA.10 anchors, PathIdsPathId/PathSlice citations for the C.23 W2 AdmissibilityLedger & rung changes
G.10‑7Ingest_InteropSurface?(optional) G.13 InteropSurface@ContextAnnotated pack notes citing external‑index editions

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 governing-definition assignment and must not become the governing definition.

G.10:4.5 - Consequence of governing-definition assignment (normative boundary statement)

G.10 is the one governing definition 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.

G.10:4.6 - Extensions (pattern‑scoped; non‑core)

All method‑/generator‑/interop‑specific shipping extension declarations live here as GPatternExtension blocks.

G.10:4.6.1 - GPatternExtension — G.10:Ext.QDArchiveShippingPins

PatternScopeId: G.10:Ext.QDArchiveShippingPins GPatternExtensionId: QDArchiveShippingPins GPatternExtensionKind: MethodSpecific GoverningPatternId: C.18 Uses: {C.18, C.21, G.5, G.8, G.11} ⊑/⊑⁺: ∅ RequiredPins/EditionPins/PolicyPins (minimum):

  • DescriptorMapRef.edition
  • DistanceDefRef.edition
  • active fields from C.21’s DHC replay basis (only when shipped archive telemetry consumes a C.21 DHC coordinate; carry exactly the fields used rather than a generic method-spec or metric-edition pin)
  • 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.

G.10:4.6.2 - GPatternExtension — G.10:Ext.OEEShippingPins

PatternScopeId: G.10:Ext.OEEShippingPins GPatternExtensionId: OEEShippingPins GPatternExtensionKind: GeneratorSpecific GoverningPatternId: G.5 Uses: {G.5, G.11} ⊑/⊑⁺: ∅ RequiredPins/EditionPins/PolicyPins (minimum):

  • TransferRulesRef.edition
  • EnvironmentValidityRegion? (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 defined by the governing pattern; the pack only carries the pins required to make the shipped claim replayable/auditable.

G.10:4.6.3 - GPatternExtension — G.10:Ext.InteropCitation

PatternScopeId: G.10:Ext.InteropCitation GPatternExtensionId: InteropCitation GPatternExtensionKind: InteropSpecific GoverningPatternId: G.13 Uses: {G.13} ⊑/⊑⁺: ∅ RequiredPins/EditionPins/PolicyPins (minimum):

  • InteropSurfaceId
  • ExternalIndexRef.edition
  • ClaimMapperRef.edition
  • PlaneMapRef.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.

G.10:4.7 - Published surfaces must ship kind, source, derivation, lens, and shortlist token

  • Published surfaces should carry the subject kind, source set kind, and relevant declared surface pins. When a selector outcome is shipped, they should also carry its outcome kind and, when applicable, the set-result kind or handoff kind.
  • These are publication payload metadata fields inside SoTA-Pack(Core), not publication face kinds, publication form kinds, interop publication form kinds, or carrier kinds.
  • Good publication fields include selectorOutcomeKind, setResultFamily, handoffKind, subjectKind, sourceSetFamily, sourceSetComposition, 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 declared qId or reachability rule id that disciplined that derivation.
  • portfolioMode may 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, or shortlist language.
  • It should not redefine that semantics locally.
  • When one shipped surface still needs a plain-language label, use the declared set-result kind and source set rather than falling back to portfolioMode.

G.10:4.7.1 - Worked publication slice

  • If the visible surface is one tradition front under the declared Q, publish sourceSetFamily=Front, derivedViewKind=TraditionFront, and keep basePaletteRef=SoTAPaletteDescriptionId recoverable instead of pretending that the palette itself already was that front. Publish selectorOutcomeKind only when a G.5 selector outcome is also shipped, and setResultFamily only for its SetResultOutcome branch.
  • If one shortlist is emitted from that derived tradition front, publish selectorOutcomeKind=SetResultOutcome, setResultFamily=Shortlist, sourceSetFamily=Front, derivedViewKind=TraditionFront, basePaletteRef=SoTAPaletteDescriptionId, and the named lensId together.
  • 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 sourceSetFamily=Archive, derivedViewKind=TraditionArchive, and keep the same basePaletteRef recoverable. A G.5 selector outcome, when also shipped, carries its admitted outcome kind and, only for a SetResultOutcome, its set-result kind.
  • If the shortlist is later ordered, publish setResultFamily=RankedShortlist and keep the declared source set visible.
  • Use ChoiceSet only as a mathematical gloss when the shipped object is explicitly one mathematical analysis artifact rather than the public selected set; it is not a setResultFamily value.
  • Do not publish sourceSetFamily=TraditionPalette alone 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 TraditionFront or TraditionArchive as if they were the default meaning of Tradition.
  • Do not ask portfolioMode to tell the reader whether they are seeing one palette, one front, one archive, or one shortlist.