40 Glossary
Key Terms and Artefact Families
This glossary defines the key terms used throughout the manuscript in the precise sense the framework assigns them. Terms are listed alphabetically. The section where each term is first formally introduced is noted.
40.1 Analytical backbone
Introduced in: §3.7
The governed persistence layer in which all artefacts are stored, linked, and made queryable across runs, futures, epochs, and module versions. The backbone is append-only, schema-governed, lineage-linked, and technology-neutral. It is a methodological commitment, not merely a database: its governance properties are what make AI-assisted interrogation of analytical results trustworthy.
40.2 Artefact
Introduced in: §3.5
A governed analytical object: a structured, versioned, validated, and provenance-carrying output that has been admitted to the comparison chain through an explicit acceptance gate. An artefact is not merely a file or a model output. It is an output that has been materialised in a schema-conforming form, linked to the run and future conditions that produced it, passed through a validation gate, and stored in the backbone with explicit lineage.
40.3 Decision-centred modelling
Introduced in: §0.1
An approach to planning analysis in which the analytical environment is organised around the requirements of the decision being supported, specifically the alternatives, futures, consequences, and evaluative metrics that the decision requires, rather than around the internal logic of any one model class. The decision problem is the primary object of analysis; models are instruments in service of that analysis.
40.4 Decision-first boundary principle
Introduced in: §0.3
The foundational commitment of the framework: analytical boundaries are drawn primarily by the decision context and the consequences that must remain visible for comparison, not by the physical extent of the system being studied. The decision makes the boundary; the artefact makes the connection.
40.5 DecisionSummaryArtefact
Introduced in: §3.5
The evaluation layer’s primary output artefact. Carries the regret, robustness, satisficing, and threshold-violation metrics for each pathway alternative across the future ensemble. Its credibility depends on the governance of the upstream artefact chain.
40.6 Deep uncertainty
Introduced in: §1.3
Conditions in which stakeholders cannot agree on the appropriate models, the probability distributions of key parameters, or the metrics by which outcomes should be judged. Deep uncertainty is structural indeterminacy, not merely parameter noise. It requires exploration across many plausible futures rather than optimisation under one presumed future.
40.7 DemandPack
Introduced in: §3.5
The canonical demand artefact. A time-resolved, versioned, acceptance-gated record of site-level heat demand for a specific epoch, scenario variant, and future condition. Produced by the site demand construction module and consumed by the site dispatch module.
40.8 DMDU (Decision Making under Deep Uncertainty)
Introduced in: §1.3
The intellectual tradition that reorients analytical practice from optimising against a single forecast toward characterising how decisions perform across a wide ensemble of plausible futures. Key methods include Robust Decision Making (RDM), Dynamic Adaptive Policy Pathways (DAPP), Exploratory Modelling and Analysis (EMA), and scenario discovery methods including PRIM and CART.
40.9 FutureArtefact
Introduced in: §3.5
The canonical uncertainty artefact. Records the specific combination of uncertain driver values under which a given pipeline run was executed. Every other artefact produced in that run carries a foreign key reference to its governing FutureArtefact.
40.10 GXP (Grid Exit Point)
Introduced in: §5.2
In the New Zealand electricity system, the metered boundary between the national transmission grid and a regional distribution network. GXP-level hosting capacity is the primary infrastructure constraint governing electrification feasibility in the Southland regional context.
40.11 IncrementalElectricityPack
Introduced in: §3.5
The canonical electricity interface artefact produced by the site dispatch module and consumed by the regional electricity module. Carries the compact signal descriptors representing the site’s electricity demand increment at the GXP boundary. It is the thin-waist object at the site-to-regional boundary.
40.12 Module
Introduced in: §3.2
An analytical component of the modelling environment defined by four properties: a declared analytical role, declared inputs, declared outputs, and an explicit interface contract. A module is defined by its role and interface contract, not by its implementation. Implementations may change freely provided the interface contract is preserved.
40.13 One-pass coupling
Introduced in: §6.1
The coupling pattern implemented in the current proof of concept: modules run in a defined sequence without iterative feedback. The site dispatch module produces the incremental electricity signal; the regional screening module evaluates grid constraints; results are aggregated without looping. Declared as a current limitation of the proof of concept.
40.14 Paired-futures requirement
Introduced in: §1.4
The design requirement that competing pathway alternatives must be evaluated under identical external conditions in every future. Regret comparisons between pathways evaluated under different futures are confounded. The FutureArtefact schema and paired-futures enforcement logic enforce this requirement.
40.15 Progressive refinement
Introduced in: §0.3
The framework’s development philosophy. A minimal implementation that is architecturally complete and analytically useful precedes any richer components. The architecture reveals its own next development steps through regret sensitivity diagnostics. Complexity is added where it improves decision quality, not where it increases formal sophistication.
40.16 RDM (Robust Decision Making)
Introduced in: §1.3
A DMDU method developed principally at RAND by Lempert, Popper, and Bankes. Evaluates alternatives across large ensembles of futures using regret, satisficing frequency, and vulnerability diagnostics rather than expected-value optimisation.
40.17 Regret
Introduced in: §1.5
The difference between what the best available alternative would have achieved under a given future and what the chosen alternative achieves under that same future. Regret is future-specific and comparative. It is zero for the preferred alternative under each future and positive for all others.
40.18 ResultArtefact
Introduced in: §3.5
Records the site-level and system-level consequences for a specific pathway alternative, epoch, and future. Carries annual cost decompositions, energy consumption, emissions, and adequacy metrics.
40.19 Robustness
Introduced in: §1.5
A property of a strategy that performs acceptably or competitively across many plausible futures. A robust strategy need not be optimal under any single future; its value lies in avoiding large failures and remaining acceptable across a wide range of conditions the decision-maker cannot control.
40.20 Satisficing
Introduced in: §1.5
A decision standard that asks which alternatives meet stated thresholds of acceptability across futures, rather than which is nominally optimal. Follows Herbert Simon’s concept of bounded rationality. The satisficing rate is the fraction of ensemble futures in which an alternative meets all declared thresholds.
40.21 SignalsPack
Introduced in: §3.5
The canonical electricity interface artefact produced by the regional module and consumed by the site dispatch module and the evaluation layer. Carries GXP-level signals including adequacy headroom, tariff adders, scarcity proxies, upgrade-class indicators, and confidence scores.
40.22 Site decision robustness overlay
Introduced in: §6.7
A post-processing module that consolidates site dispatch cost summaries with grid RDM summaries to produce a pathway comparison reflecting uncertainty in both site-level cost components and regional infrastructure conditions. It is a post-processing overlay only: it does not re-run dispatch, modify existing artefacts, or introduce feedback loops.
40.23 System-level regret
Introduced in: §4.4
The divergence between the regret computed under the site-only cost assessment and the regret computed under the infrastructure-conditional system cost assessment. Positive system-level regret indicates that current pricing arrangements create incentives for site operators to pursue pathway choices that impose costs on the regional system that they do not privately bear. Formally derived in Sub-Module SM-4.4-A.
40.24 Thin waist
Introduced in: §0.5
The design principle that what is exchanged between modules must be narrow, explicit, and stable, while what happens inside each module may evolve freely. The thin waist separates the stability of the interface from the flexibility of the implementation. It is a design principle, not a data format.
40.25 ValidationArtefact
Introduced in: §3.5
The governance artefact. Records the outcome of every acceptance gate check applied to every other artefact. Failed ValidationArtefacts are retained in the backbone alongside their associated failed artefacts as permanent governance records.
Framework Extension Registry
This registry declares planned additions to the manuscript that are specified but not yet implemented as full sections. It follows the same Implemented / Specified / Vision taxonomy as the Node Declaration system.
40.25.1 Planned Sub-Modules (Specified)
| ID | Title | Parent section | Status | Description |
|---|---|---|---|---|
| SM-5.5-A | TIMES-NZ and the NZ Energy Modelling Ecosystem | §5.5 | ✓ Added | Detailed ecosystem assessment and integration pathways |
| SM-3.9-A | External Reference Registry and ReferenceArtefact | §3.7 | ○ Specified | Governance specification for external document linkage |
| SM-6.7-A | Iterative Coupling: Two-Pass Architecture | §6.10 | ○ Specified | Design for closing the one-pass coupling limitation |
| SM-7.4-A | Surrogate-Accelerated Ensemble: Implementation Guide | §7.4 | ○ Specified | Step-by-step ML surrogate training and validation |
40.25.2 Planned Sections (Vision)
| ID | Title | Placement | Status | Description |
|---|---|---|---|---|
| §5.7 | Knowledge Context Layer | After §5.6 | ◇ Vision | Structured manifest linking all FutureArtefact fields to primary data sources |
| §7.10 | The Academic Attestation Platform | After §7.9 | ◇ Vision | Claim-level expert attestation as scholarly communication infrastructure |
| §8.1–§8.6 | Module 8: Community Contributions | New module | ◇ Vision | Domain instantiations contributed by the research community |
40.25.3 Planned Artefact Family Extensions
| Family | Status | Description |
|---|---|---|
| ReferenceArtefact | ○ Specified | Governed external document registry; schema in SM-3.5-A |
| AdaptiveSignalArtefact | ◇ Vision | Monitoring and signpost records for DAPP pathway revision |
| CommunityArtefact | ◇ Vision | Contribution records from community extension process |