FPF Reference

    G.12:4.2 — Method‑of‑Obtaining Output (generation‑first; design‑time → run‑time)

    Preface node heading:g-12-4-2-method-of-obtaining-output-generation-first-design-time-run-time:81993

    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

    Stage A — Author & bind (design‑time)

    A1. Select the DHC slot set (governed by C.21). Choose DHCSlotId[] from C.21 (typed DHC slots), and declare the series scope explicitly as TargetSlice (USM tuple) plus an explicit time selector (Γ_time per row; optionally a WindowSpec that generates the row windows). Do not restate slot semantics in the dashboard kit; cite the C.21 governing definitions.

    A2. Bind governance card and legality gate (governing definitions: A.19, G.0). Pin CNSpecRef.edition and CGSpecRef.edition. Any normalization or numeric comparability assumptions are expressed by explicit CN‑Spec artefacts (ids/refs) and any numeric legality requirements cite CG‑Spec artefacts (SCP / MinimalEvidence / Γ‑fold pins as applicable). The dashboard does not introduce local “shadow specs”. If the dashboard series/slice actually uses cross‑Context or cross‑plane routing, it MUST additionally pin the relevant crossing and penalty‑policy surfaces as ids (Bridge/CL/plane ids, Φ/Ψ/Φ_plane policy‑ids, PlaneMapRef.edition?) and cite their governing patterns (typically G.7 for bridge calibration/CL kits, pinned through G.Core). The dashboard MUST NOT encode a dashboard‑local “penalty regime”.

    A3. Pin computation methods (governed by C.21). For each slot/method used to compute a time series value, record DHCMethodSpecRef.edition and DHCMethodRef.edition (table‑backed, per C.21). The dashboard series is edition‑aware: if a method spec changes, the dashboard either forks the series edition or emits telemetry and refreshes under explicit pins.

    A4. Declare optional panels via Extensions only. If the dashboard depends on (i) selector set-result outputs, (ii) QD illumination / archive telemetry, (iii) open‑endedness telemetry, (iv) maturity ladder views, or (v) pack inclusion, then the relevant GPatternExtension block(s) in G.12:4.9 MUST be present and their pins MUST be satisfied.

    Stage B — Compute rows (run‑time; Work/Audit)

    B1. Resolve evidence by Path (governed by G.6). Compute rows from evidence cited as PathSliceId[] (and PathId[] when needed), under the declared window/freshness regime. Preserve lane discipline and handle missingness using tri‑state stances governed by G.Core.

    B2. Compute slot values using pinned methods (governed by C.21). Compute each slot value by applying the pinned DHCMethodRef.edition/DHCMethodSpecRef.edition under the pinned governance card and legality gate. Enforce “no illicit arithmetic” for ordinals/categoricals as a dashboard‑kit obligation (see CC‑G12.*). Any cross-Context or cross-plane use is expressed only via explicit crossing pins (Bridge/Plane routing) and policy ids governed by G.Core.

    B3. Emit RSCR‑actionable telemetry pins (governing definition: G.11). When any of the declared pins/editions/policies/windows/evidence slices change, emit DHCTelemetryPin events with canonical RSCRTriggerKindId and payload pins sufficient for slice‑scoped refresh planning.

    Stage C — Publish series & slices (run‑time; publication)

    C1. Publish DHCRow@Context and DHCSeries@Context as UTS publication units. Mint/publish UTS rows with Tech/Plain twins and include the required pins (window, reference plane, method editions, evidence paths).

    C2. Publish DashboardSlice@Context as a view‑only projection. Slices are groupings/annotations over already computed rows; they must not redefine legality, acceptance, or scalarization.

    C3. Wire refresh via telemetry pins (no orchestration governance). Dashboards emit pins; refresh orchestration remains governed by G.11.

    Last Updated: 2026-06-08 — upstream FPF commit 093d30e8 (github.com/ailev/FPF)