#G.12 — DHC Dashboards (Discipline‑Health time‑series; admissible telemetry; generation‑first)

Preface node heading:g-12-dhc-dashboards-discipline-health-time-series-admissible-telemetry-generation-first:81841

#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

Tag: Architectural kit pattern (conceptual; notation‑independent; dashboard‑kit governing definition)

Stage: design‑time authoring → run‑time computation & publication (series and slices); refresh/RSCR‑wired

Primary hooks: G.Core (core invariants, linkage catalogues, RSCR trigger catalogue, Default Governing Definition Index), C.21 (DHC slots + DHCPack / DHCMethodSpec / DHCSeries artefacts), G.6 (EvidenceGraph; PathId/PathSliceId citation), G.7 (Bridge calibration / CL & Φ/Ψ/Φ_plane policy surfaces; when crossings/plane routing is used), G.11 (telemetry‑driven refresh/decay orchestration), G.5 (selector set-result / set‑returning outputs, when dashboard consumes performance trade‑offs), A.19 (CN‑Spec governance card), G.0 (CG‑Spec legality gate), F.17/F.18 (UTS + twin labels), E.5.2 (notation independence), E.10 (LEX discipline). (Optional, extension‑gated hooks: G.2 (SoTA palette & DHC alignment hooks), C.18 and C.19 (QD / E‑E / OEE telemetry pins), G.8 (SoS‑LOG bundle & maturity ladder view), G.10 (shipping inclusion of dashboard slices).)*

Why this exists. C.21 defines what lawful “discipline health” slots are (CHR‑typed; scale/legality aware; freshness‑windowed), but it does not, by itself, provide a generation‑first method for producing edition‑pinned, evidence‑citable DHC time series that remain refreshable under RSCR. G.12 is that dashboard method: it defines the dashboard kit surfaces (DHCSeries@Context, DHCRow@Context, DashboardSlice@Context, telemetry pins) and a pipeline for computing and publishing DHC readings without shadow specs, without illicit arithmetic, and without smuggling scalar winners out of partial orders or telemetry.

Modularity note. G.12 governs dashboard publication units and wiring only. It does not govern CN-Spec, CG-Spec, CHR, CAL, selection semantics, evidence semantics, shipping, or refresh heuristics. It binds to those governing definitions via refs/pins/editions/policy‑ids and keeps any method‑/generator‑specific panels strictly inside Extensions (GPatternExtension blocks).

#G.12:1 — Intent

Produce admissible, reproducible, refresh-aware discipline-health dashboards by turning C.21 DHC definitions into:

1. a UTS‑published time series (DHCSeries@Context) whose rows are evidence‑citable by PathId/PathSliceId,
2. a dashboard slice view (DashboardSlice@Context) that is view‑only (no hidden re‑aggregation or “new objectives”), and
3. telemetry pins that allow G.11 to plan slice‑scoped refresh (rather than “rerun everything”).

#G.12:2 — Problem frame

Dashboards routinely drift or become illegal when they:

• mix scales (ordinal treated as interval; “average maturity level”),
• hide normalization and re‑parameterization (“normalized score” with no CN‑Spec pins),
• silently cross Contexts or planes (implicit reuse without explicit Bridge/Plane routing),
• fail to pin editions of computation methods, descriptor spaces, or distances,
• turn selected sets or archives into a single scalar “winner” by dashboard fiat,
• cannot refresh selectively (no actionable telemetry pins; only narrative “this changed”).

We need a dashboard kit that makes the method of obtaining dashboard values explicit and auditable, while keeping universal invariants governed in G.Core.

#G.12:3 — Forces

• Legality and comparability are governed by CN-Spec and CG-Spec. Dashboards must not invent local legality/acceptance/normalization “mini‑specs”; they pin and cite CN‑Spec and CG‑Spec surfaces as required by G.Core conformance.
• Ordinal discipline is non‑negotiable. The most common dashboard failure mode is illicit arithmetic on ranks/categories; the kit must make “compare‑only” enforceable.
• Set‑returning discipline survives into views. Dashboards must not silently scalarize partial orders or selector selected-set results; any scalarization/promotion is an explicit governing-pattern policy cited through G.Core conformance; semantics are governed by the relevant pattern or policy.
• Edition‑awareness is the difference between “trend” and “drift”. If the method definition changes, the dashboard must either (i) fork series edition, or (ii) emit telemetry and refresh slices under pinned conditions.
• RSCR must be actionable. Causes are emitted as canonical ids (typed trigger kinds + id‑valued pins), not prose.

#G.12:4 — Solution — Compute and publish DHC series admissibly, with RSCR-ready telemetry

#G.12:4.0 — G.Core linkage (normative)

This pattern is core‑invariant‑bearing and therefore binds to G.Core by declaration (not by restating invariants here).

GCoreLinkageManifest (G.12) (normative; expands per G.Core:4.2) 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.BridgeCalibrationKit }

• RSCRTriggerKindIds := { RSCRTriggerKindId.LegalitySurfaceEdit } (Any additional causes required by optional dashboard panels MUST be introduced only by the corresponding GPatternExtension blocks in G.12:4.9.)

• DefaultsConsumed := ∅ (Default-citation discipline for DefaultId.PortfolioMode and DefaultId.DominanceRegime is only relevant when selection outputs with PortfolioMode are consumed; see G.12:Ext.PortfolioTelemetry.)

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

• CorePinsRequired (pattern delta; pin names only; all are id‑valued unless noted) := { DHCSeriesId, TargetSlice (USM tuple; varies only by Γ_time across rows; no implicit “latest”), Γ_time (time selector / freshness window; required per row; series MAY additionally declare a window‑family spec), DHCSlotId[] (typed DHC slots governed by C.21; each resolves to CharacteristicId + scale/unit/polarity + reference plane binding + lane discipline), DHCMethodSpecRef.edition, DHCMethodRef.edition, PathSliceId[] } (Nil‑elision applies. All other definition pins are conditional: they MUST appear only when actually used and when their governing pattern/extension is present (e.g., UNM/normalization pins, QD/OEE telemetry pins, transfer rules pins, pack inclusion pins).)

• TriggerAliasMapRef := ∅

#G.12:4.1 — Objects (LEX heads; twin‑register discipline)

All objects below are notation‑independent; serialisations (if any) live under shipping or interop governance, not here.

(1) DHCSeries@Context (UTS‑published dashboard series; C.21‑grounded) A time‑indexed publication of computed DHC readings for a Discipline × ContextSlice, aligned with U.DHCSeries semantics from C.21 and pinned to method/governing spec refs.

Minimal fields (conceptual; ids/pins only):

DHCSeries@Context := ⟨ DHCSeriesId, CG-FrameContext, entityOfConcern := ⟨GroundingHolon, ReferencePlane⟩, TargetSlice, // USM tuple; time series varies Γ_time across rows (explicit, no implicit “latest”) DHCSlotId[], // slot set selected from C.21 (typed DHC slots; not “just Characteristic ids”) DHCPackRef.edition?, DHCMethodSpecRef.edition, WindowSpec?, // optional window-family spec used to generate per-row Γ_time CNSpecRef.edition, CGSpecRef.edition, EvidenceGraphId?, // if resolvable; else row-level Path pins suffice DashboardSliceId[]?, // published view slices (optional) TelemetryPinSetId? // wiring to refresh (conceptual) ⟩

(2) DHCRow@Context (one timepoint / window reading; Work/Audit‑citable) A single computed row of the series.

DHCRow@Context := ⟨ DHCRowId, DHCSeriesId, Γ_time, DesignRunTag = run, DHCSlotId, value, units/scaleRef?, compareOnly?, stance ∈ {pass|degrade|abstain}, DHCMethodRef.edition, DHCMethodSpecRef.edition, PathSliceId[], PathId[]?, EvidenceGraphId?, evidenceLaneTags? := {TA|VA|LA}, crossingPins? := ⟨BridgeId[], PlaneMapRef.edition?, CL/CL^k/CL^plane?, Φ/Ψ/Φ_plane policy‑ids…⟩ ⟩

(3) DashboardSlice@Context (view; non‑semantic) A view‑friendly grouping over one or more series/rows. It MUST NOT introduce new aggregation/legality semantics; it is a projection over already computed, pinned, citable rows.

DashboardSlice@Context := ⟨ DashboardSliceId(UTS), DHCSeriesId(UTS)[], SliceAnnotations?, // labels, grouping metadata, explanatory text ViewSpecId?, // view template id (policy‑bound; no semantics implied) IncludedRowIds? ⟩

(4) DHCTelemetryPin (refresh wiring pin; id‑based causes) A conceptual telemetry pin emitted to refresh/orchestration (governed by G.11) with canonical trigger kind ids.

DHCTelemetryPin := ⟨ triggerKindId: RSCRTriggerKindId, scope: PathSliceId[] | PatternScopeId, payloadPins: { …ids… } // editions, policy‑ids, UTS row ids, window ids, etc. ⟩

Ref discipline. .edition SHALL appear only on …Ref (per E.10). Dashboard artefacts that mint public ids publish Tech/Plain twins (UTS discipline).

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

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.

#G.12:4.9 — Extensions (pattern‑scoped; non‑core)

Extension rule (Phase‑2). Anything method‑, generator‑, or view‑family‑specific belongs here, as GPatternExtension modules. These modules may add mode‑specific definition pins and additional RSCR trigger kinds, but MUST NOT redefine Part‑G‑wide invariants or defaults.

#G.12:Ext.SoTAPalette — SoTA palette & DHC alignment hooks (optional)

PatternScopeId: G.12:Ext.SoTAPalette GPatternExtensionId: SoTAPalette GPatternExtensionKind: InteropSpecific GoverningPatternId: G.2 (SoTA palette + DHC alignment hooks semantics are governed by G.2; G.12 only wires them) Uses: {G.2} ⊑/⊑⁺: ∅

RequiredPins/EditionPins/PolicyPins (minimum):

• SoTA_PackRef.edition?
• DHC-SenseCellId[]? (when series pins to DHC alignment hooks / sense‑cell inventories)
• DHCAlignmentHookId[]?

RSCRTriggerKindIds (delta): ∅

#G.12:Ext.PortfolioTelemetry — selector set-result integration panel

PatternScopeId: G.12:Ext.PortfolioTelemetry GPatternExtensionId: PortfolioTelemetry GPatternExtensionKind: MethodSpecific GoverningPatternId: G.5 (PortfolioMode citation plus selected-set semantics and set‑return discipline) Uses: {G.5, G.6} ⊑/⊑⁺: ∅

RequiredPins/EditionPins/PolicyPins (minimum):

• TaskSignatureRef? (when PortfolioMode semantics depend on TaskSignature traits)
• DominanceRegime (cite the governing definition for DefaultId.DominanceRegime; publish the resolved regime, do not invent a local default)
• PortfolioMode (cite the governing definition for DefaultId.PortfolioMode; publish the resolved mode)
• SCRId/DRRId (or equivalent selector evidence pins, when dashboard row depends on selector outcomes)

DefaultsConsumed: {DefaultId.DominanceRegime, DefaultId.PortfolioMode} (cite governing definitions through G.Core.DefaultGoverningDefinitionIndex; no local defaults)

RSCRTriggerKindIds (delta): ∅ (base triggers suffice; any extra triggers must be explicit)

Notes (wiring‑only):

• The dashboard may visualise selected-set / Archive telemetry, but MUST keep set‑returning semantics; any scalar “headline number” is a view projection, not a legality‑bearing decision.

#G.12:Ext.QDTelemetry — illumination / archive telemetry panel

PatternScopeId: G.12:Ext.QDTelemetry GPatternExtensionId: QDTelemetry GPatternExtensionKind: MethodSpecific GoverningPatternId: C.18 (QD / NQD‑CAL semantics; descriptor/distance/insertion policy) Uses: {C.18, G.5, G.11} ⊑/⊑⁺: ∅

RequiredPins/EditionPins/PolicyPins (minimum):

• DescriptorMapRef.edition
• DistanceDefRef.edition
• CharacteristicSpaceSpecRef.edition? (iff the descriptor or characteristic space is editioned as a published surface; required for view reproducibility)
• InsertionPolicyRef
• EmitterPolicyRef?
• ArchiveSnapshotRef? (id/pin for the published archive snapshot, if any)
• PathSliceId[] (scope for refresh; slice‑keyed)

RSCRTriggerKindIds (delta): ∅ (base trigger set already includes RSCRTriggerKindId.TelemetryDelta; add only genuinely additional kinds here)

Notes (wiring‑only):

• Illumination/coverage signals are treated as telemetry. Any promotion of telemetry into selection dominance is governed elsewhere (typically CAL policy; pinned through G.Core).
• If descriptor characteristics are surfaced as published identifiers (not just local UI text), they MUST follow the Tech/Plain twin-label discipline (UTS Name Cards); otherwise they remain non-normative view annotations.

#G.12:Ext.OpenEndedTelemetry — open‑endedness / transfer telemetry panel

PatternScopeId: G.12:Ext.OpenEndedTelemetry GPatternExtensionId: OpenEndedTelemetry GPatternExtensionKind: GeneratorSpecific GoverningPatternId: C.19 (E/E‑LOG & exploration accounting; generator/transfer telemetry wiring) Uses: {C.19, G.5, G.11} ⊑/⊑⁺: ∅

RequiredPins/EditionPins/PolicyPins (minimum):

• TransferRulesRef.edition (when transfer rules are part of the telemetry interpretation)
• EnvironmentValidityRegionId?
• ProbeBudgetPolicyId?
• PathSliceId[]

RSCRTriggerKindIds (delta): ∅ (base trigger set already includes RSCRTriggerKindId.TelemetryDelta; add only genuinely additional kinds here)

Notes (wiring‑only):

• Open‑endedness metrics are telemetry‑level artefacts; dashboards must not silently convert them into “dominance objectives”.

#G.12:Ext.MaturityLadderPanel — maturity ladder view (optional)

PatternScopeId: G.12:Ext.MaturityLadderPanel GPatternExtensionId: MaturityLadderPanel GPatternExtensionKind: DisciplineSpecific GoverningPatternId: G.8 (maturity ladder semantics in SoS‑LOG bundle/maturity cards) Uses: {G.8, G.6, G.11} ⊑/⊑⁺: ∅

RequiredPins/EditionPins/PolicyPins (minimum):

• MaturityCardRef
• MaturityRungId?
• PathId/PathSliceId (evidence citations for rung claims)

RSCRTriggerKindIds (delta): {RSCRTriggerKindId.MaturityRungChange}

#G.12:Ext.PackInclusion — shipping inclusion stub (optional)

PatternScopeId: G.12:Ext.PackInclusion GPatternExtensionId: PackInclusion GPatternExtensionKind: InteropSpecific GoverningPatternId: G.10 (shipping semantics are governed by G.10) Uses: {G.10} ⊑/⊑⁺: ∅

RequiredPins/EditionPins/PolicyPins (minimum):

• SoTA‑PackId
• DashboardSliceId(UTS) (or DHCSeriesId(UTS) when shipping series directly)
• CNSpecRef.edition, CGSpecRef.edition (as shipped pins, per G.10 wiring)

RSCRTriggerKindIds (delta): ∅

Notes (wiring‑only):

• This module is a wiring stub: it does not define shipping behaviour; it only states which dashboard artefacts may be cited by SoTA‑Pack(Core).

#G.12:Ext.ViewFamilySeed — advanced view families (Phase‑3 seed; governing pattern TBD)

PatternScopeId: G.12:Ext.ViewFamilySeed GPatternExtensionId: ViewFamilySeed GPatternExtensionKind: Phase3Seed GoverningPatternId: governing pattern not yet selected Uses: {} ⊑/⊑⁺: ∅

Notes (Phase‑3 seed; non‑normative):

• Placeholder for advanced dashboard view families (e.g., embedding‑based similarity panels, predictive drift detectors, change‑point overlays). Any such module must remain policy‑bound and must not introduce new Part‑G‑wide norms.

#G.12:5 — Interfaces (conceptual; kit surface)

(No file formats are introduced here; serialisation recipes live under shipping or interop governance.)

#G.12:6 — Conformance checklist (CC‑G12, normative)

#G.12:7 — Bias‑Annotation (informative)

• Didactic: dashboard publication units publish pins and paths first; views second.
• Architectural: no “dashboard‑local governing spec refs”; invariant citation is via G.Core.
• Pragmatic: slice‑scoped refresh is enabled by canonical trigger ids + payload pins.
• Epistemic: compare‑only ordinals and explicit provenance prevent “trend‑as‑drift”.

#G.12:8 — Consequences

• Dashboards become reproducible artefacts, not screenshots. A DHCRow@Context is re‑derivable under pinned editions and evidence windows.
• Selective maintenance becomes possible. Telemetry pins let G.11 refresh what changed (path slice / window / method edition), rather than rerunning the entire pipeline.
• Illicit scalarization is structurally discouraged. Set‑returning and CN/CG-governed semantics are preserved into the dashboard layer.

#G.12:9 — Relations

Builds on: G.Core, C.21, G.6, G.11, A.19, G.0, F.17/F.18, E.5.2, E.10. Coordinates with: G.5 (when selector set-result outputs are consumed), G.7 (when crossings/plane routing or CL/Φ/Ψ/Φ_plane policy pins are used), G.8 (when maturity ladder view is included), G.10 (when dashboard slices are shipped). Constrains: dashboard consumers: dashboards are projections over pinned, evidence‑citable rows; they do not mint new governing-spec semantics.

#G.12:10 — Author’s quick checklist

1. Declare the dashboard series scope: TargetSlice (USM tuple), ReferencePlane, and an explicit Γ_time regime (per‑row; optionally a WindowSpec that yields the row windows).
2. Select DHCSlotId[] and cite C.21 (do not restate slot semantics).
3. Pin DHCMethodSpecRef.edition and DHCMethodRef.edition for every computed slot/value (plus any other definition pins actually used).
4. Ensure rows are evidence‑citable by PathSliceId[] and include explicit Γ_time (row is run‑time: DesignRunTag = run).
5. Publish UTS publication units with twins and the required pins.
6. Emit canonical telemetry pins (RSCRTriggerKindId + scope + payload pins) for G.11.
7. If SoTA palette hooks / selection / QD / OEE / maturity / shipping panels are needed, add the corresponding G.12:Ext.* blocks and satisfy their pins.

#G.12:11 — Worked micro‑examples (informative; SoTA‑oriented)

(A) Decision‑making discipline dashboard (multi‑tradition). Slots (from C.21): ReproducibilityRate (freshness‑windowed), StandardisationLevel (ordinal), AlignmentDensity (bridge density over DHC‑SenseCells), MetaDiversity (operator family diversity), DisruptionBalance (target‑band metric). Evidence: citation graphs, benchmark traces, and bridge calibrations are referenced via PathSliceId[]. Optional panels:

• G.12:Ext.PortfolioTelemetry to visualise set‑returning method selected sets without forcing a scalar winner.
• G.12:Ext.QDTelemetry to include illumination/archive telemetry using modern QD families (e.g., CMA‑ME / policy‑gradient QD variants / surrogate‑assisted illumination lines) as telemetry.

(B) Evolutionary software architecture dashboard (open‑endedness‑aware). Slots: stability/reproducibility metrics, standardisation stages (ordinal), cross‑paradigm alignment density, and disruption balance. Optional panels:

• G.12:Ext.OpenEndedTelemetry to include open‑endedness telemetry (environment diversity / transfer events) using POET‑style and related post‑2015 open‑ended generation families, while keeping such signals in telemetry unless an explicit governing-pattern policy promotes them.

#G.12:End

---

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