fpf.tools
Library / First Principles Framework (FPF) - Core Conceptual Specification
Jump to passage
In this reading
Source · lines 119049–119083

Link to current text

Published source confirmed at last check

Source changed 2026-10-03 08:25:59 UTC · snapshot created 2026-10-03 08:26:43 UTC · last check 2026-10-03 08:50:20 UTC

G.11:4.2 - Refresh orchestration kit (subject-qualified; conceptual artefacts)

G.11 defines a kit of authoring-plane artefacts for actual refresh planning and reporting. RefreshPlanId is required on a plan and RefreshReportId on a report. The linkage manifest applies to the triggers and actions that occur; retaining applicable support creates no trigger, plan or report merely to fill their pins.

  1. RefreshQueue (conceptual queue). A queue of refresh candidates keyed by scope (PathSliceId preferred; PatternScopeId permitted). Ordering, prioritization, and batching are policy-bound (and therefore extension-scoped), but every queue item carries canonical trigger kind ids.

  2. RefreshPlan@Context (one exact U.WorkPlan). A planned refresh is one U.WorkPlan episteme under A.15.2. It does not execute Work and does not embed gate decisions. RefreshPlan@Context is only this pattern’s application name for the plan; it declares:

    • RefreshPlanId (UTS-published id; editioned)
    • EntityOfConcernRef and ReferencePlane pins (by ref; no implicit widening)
    • TargetScope := PathSliceId[] | PatternScopeId[]
    • PlannedTriggers := RSCRTrigger[] (canonical trigger kind ids, scope, and payload pins)
    • PlannedActions := RefreshAction[] (each action delegates to a subject pattern)
    • RequiredPins: exact affected source and result editions, policy pins and scope for replayability; UTS pins for public identities actually used; graph Path pins when the selected scope is graph-expressed or an independently applicable receiving contract requires them.
    • PlannedFillingRows[]? as ClaimGraph content kept inside the WorkPlan under A.15.3 when a value must be pinned against a declaration member defined by its own pattern. A row is addressed only through the WorkPlan and has no separate reference or identity.

  3. RefreshReport@Context (record of refresh Work or its audit). An execution or audit report that records:

    • RefreshReportId (UTS-published id; editioned)
    • ExecutedActions[] with links to cited artefacts governed by cited patterns (e.g., new parity report id, new pack id)
    • ObservedDeltas (telemetry deltas, admissibility changes, evidence-relation or source-relation changes) as refs and pins, not as untyped prose
    • RSCRRefs[] (any RSCR or regression harness artefacts invoked)
    • EmittedNotices[] := DeprecationNoticeId[] and EditionBumpLogId[]
    • the canonical trigger kinds actually applied (not only aliases)

  4. DeprecationNotice@Context and EditionBumpLog@Context. Controlled evolution artefacts that preserve ID-continuity:

    • DeprecationNotice explains scope, reason class (canonical trigger kind ids), and successor refs.
    • EditionBumpLog records edition increments and the pins that justify them.

    Note (normative by delegation). ID continuity and alias discipline are governed by G.Core (do not restate as local rules here).