# IX. RUNTIME

## 9.1 Visual and Runtime Object Doctrine

### 9.1.1 Dashboard object defined.

A **Dashboard Object** under the Distributed Digital Public Goods Framework means a governed visual, analytical, operational-learning, public-safe reporting, monitoring, discovery, review, readiness, contribution, or decision-support display that presents approved data, metadata, indicators, signals, evidence summaries, workflow states, portfolio status, Registry status, Marketplace status, DRI records, Observatory outputs, Campaign metrics, Foundry progress, Academy activity, Grid inputs, TRL notes, Nexus Universe outputs, or handoff dependency information within a recorded scope. A Dashboard Object may be static, interactive, real-time, near-real-time, periodic, embedded, API-driven, public-safe, controlled-public, internal, secure-room-only, data-room-only, readiness-room-only, public authority learning-room-only, capital-reader-room-only, insurance-reader-room-only, or handoff-recipient-only.

A Dashboard Object shall be treated as a governed digital-public-good object, not merely a display layer. It shall include object identity, steward, purpose, scope, source class, data-use labels, AI-use labels where applicable, sensitivity class, public-safe status, confidence labels, uncertainty labels, update cadence, access class, support class, review status, correction pathway, archive rule, and boundary notices. A Dashboard Object may support learning, interpretation, portfolio awareness, risk intelligence, evidence review, public-safe communication, and readiness discussion, but shall not create a public authority decision, public warning, official rating, certification, procurement decision, finance signal, insurance signal, community or Indigenous consent, operational command, deployment authorization, or execution authority by implication.

### 9.1.2 Visual atlas defined.

A **Visual Atlas** means a governed collection of maps, diagrams, layered visualizations, system maps, geospatial views, network maps, dependency maps, risk landscapes, WFEH-B system views, disaster-risk views, infrastructure context views, technology ecosystem views, National Portfolio views, Nexus Universe views, Observatory views, DRI views, and public-safe explanatory graphics that make complex systems legible within a bounded public-good purpose. A Visual Atlas may include geospatial layers, non-geospatial diagrams, relationship graphs, Sankey flows, causal maps, corridor maps, cluster maps, digital public-good object maps, repository maps, maturity maps, safeguard maps, data lineage maps, and handoff dependency maps.

A Visual Atlas shall preserve the distinction between visualization and authority. It may explain, orient, compare, interpret, localize, and support public-safe understanding, but it shall not become an official map, cadastral record, emergency map, public authority decision, infrastructure instruction, surveillance record, country ranking, provider ranking, investment map, insurance score, procurement map, or operational command surface. Where a Visual Atlas contains sensitive locations, critical infrastructure, protected species, community-sensitive sites, Indigenous protocol-sensitive knowledge where applicable, public authority-sensitive information, cyber-sensitive information, or health-sensitive information, it shall apply masking, aggregation, delay, access restriction, controlled-room review, public-safe transformation, and correction controls.

### 9.1.3 Digital twin object defined.

A **Digital Twin Object** means a governed representation, model, simulation environment, scenario environment, data-linked system representation, or operationally relevant abstraction that reflects selected features, relationships, behaviors, dependencies, states, or dynamics of a physical, social, ecological, institutional, technological, infrastructural, climatic, disaster-risk, WFEH-B, cyber-physical, National Portfolio, or handoff-relevant system. A Digital Twin Object may be conceptual, static, data-linked, sensor-linked, simulation-linked, scenario-linked, AI-assisted, geospatial, infrastructure-oriented, WFEH-B-oriented, disaster-risk-oriented, Observatory-linked, Studio-hosted, readiness-room-oriented, public authority learning-oriented, or handoff-context-oriented.

A Digital Twin Object shall be scoped by recorded purpose, source basis, model basis, assumptions, limitations, uncertainty, confidence, update cadence, validation status within scope, sensitivity status, public-safe interpretation rules, and correction pathway. It shall not be treated as a complete representation of reality. It shall not create operational command, deployment authorization, public authority action, official forecast, certification, public warning, financeability, insurability, procurement readiness, or execution authority by implication.

### 9.1.4 Simulation object defined.

A **Simulation Object** means a governed computational, conceptual, scenario-based, statistical, agent-based, geospatial, system-dynamics, digital twin, stress-testing, tabletop, training, or Studio-based object used to explore possible system behavior, dependencies, risks, interventions, constraints, failure modes, resilience pathways, readiness questions, safeguard implications, or handoff dependencies within a defined scope. Simulation Objects may support research, public authority learning, Academy learning, Risk Academy learning, Foundry builds, Observatory interpretation, DRI analysis, Nexus Universe demonstrations, readiness-room discussions, and public-safe Reports.

A Simulation Object shall include purpose, scope, model basis, data basis, assumptions, variables, parameters, limitations, uncertainty, confidence, scenario framing, sensitivity review, public-safe status, review status, and correction pathway. A Simulation Object shall not be presented as forecast certainty, prediction, public warning, operational instruction, official decision, finance signal, insurance score, procurement signal, certification, deployment authorization, or execution authority.

### 9.1.5 Scenario object defined.

A **Scenario Object** means a governed narrative, analytical, modeled, simulated, tabletop, stress-test, red-team, planning, learning, or public-safe interpretation object describing a possible condition, event sequence, system state, hazard interaction, cascading effect, technology pathway, governance challenge, infrastructure dependency, WFEH-B disruption, disaster-risk pathway, climate-risk pathway, cyber-physical incident, AI-related failure mode, public authority learning question, finance-readiness question, safeguard question, or handoff dependency. Scenario Objects may be qualitative, quantitative, mixed-method, model-supported, simulation-supported, digital-twin-supported, Studio-hosted, DRI-linked, Observatory-linked, Academy-linked, Foundry-linked, Reports-linked, or Nexus Universe-linked.

A Scenario Object shall make uncertainty explicit. It shall not be represented as forecast certainty, probability determination, warning, emergency instruction, official decision, rating, ranking, certification, financeability, insurability, procurement status, deployment authorization, or execution authority. Scenario use shall remain bounded by purpose, audience, sensitivity, public-safe status, review level, and correction pathway.

### 9.1.6 Studio workflow object defined.

A **Studio Workflow Object** means a governed runtime, review, simulation, demonstration, data-room, secure-room, public authority learning-room, readiness-room, capital-reader-room, insurance-reader-room, Academy, Foundry, Campaign, Reports, Grid, TRL, Registry, Marketplace, Nexus Universe, or handoff-demonstration workflow executed or prepared within Nexus Studio or a Studio-equivalent controlled environment. It may combine dashboards, APIs, data objects, model objects, AI workflows, digital twins, simulations, scenario objects, evidence packs, Registry records, Marketplace objects, Report objects, and handoff-context objects.

A Studio Workflow Object shall include workflow identity, purpose, scope, input objects, output objects, access class, permissions, tool permissions, AI-use labels, data-use labels, logging rules, no-write-back rules, no-command rules, output review, public-safe restrictions, export restrictions, shutdown triggers, correction triggers, archive rules, and boundary notices. A Studio Workflow Object is a controlled workflow environment, not a deployment environment by default.

### 9.1.7 Visualization as public-safe interpretation.

Visualization under DDPGF shall be understood as **public-safe interpretation** of approved records, not as a substitute for the underlying record, source data, method, public authority process, field verification, legal determination, finance diligence, insurance underwriting, procurement diligence, community consent process, Indigenous protocol process where applicable, or operational command process. Visual displays shall be designed to make meaning understandable without overstating certainty, authority, completeness, or readiness.

Every visual object shall preserve source notes, confidence labels, uncertainty labels, update cadence, public-safe limitations, sensitivity controls, and correction pathways. Visualization shall make complexity legible while preventing false precision, visual authority overclaim, ranking overclaim, warning overclaim, rating overclaim, finance signal overclaim, procurement signal overclaim, and operational command overclaim.

### 9.1.8 Runtime object without operational command.

Runtime Objects, including dashboards, digital twins, simulations, Studio workflows, AI workflows, data workflows, and controlled demonstrations, shall be used for learning, review, interpretation, readiness discussion, public-safe communication, evidence exploration, and handoff context preparation. They shall not issue commands to physical systems, public authority systems, emergency systems, infrastructure systems, financial systems, insurance systems, procurement systems, health systems, telecommunications systems, drones, robotics, OT systems, IoT systems, IIoT systems, or cyber-physical systems unless separately authorized outside DDPGF by competent lawful actors.

The default runtime posture shall be no-command, no-write-back, controlled-output, review-before-release, and correctionable. Any exception shall require explicit recorded authority, competent lawful basis, separate operational governance, security review, public-safe review, safeguard review, and role separation from DDPGF’s public-good object governance function.

## 9.2 Dashboard Classes

### 9.2.1 National Portfolio dashboards.

**National Portfolio Dashboards** shall present public-safe or controlled views of national priorities, challenge briefs, National Portfolio objects, Working Group outputs, Competence Cell workplans, evidence needs, Observatory needs, campaign activity, Academy activity, Foundry builds, Reports, Registry records, Marketplace objects, Grid inputs, TRL notes, Nexus Universe routing, and handoff dependency status. They shall support national ownership, national coordination, national learning, national capability formation, and lawful handoff preparation.

National Portfolio Dashboards shall not rank countries, imply government approval, issue public warnings, certify national readiness, approve providers, recommend procurement, create financeability, create insurability, grant public authority status, authorize implementation, or bypass national governance. They shall include national context notes, source notes, public-safe limits, sensitive data controls, update cadence, and correction pathways.

### 9.2.2 DRI dashboards.

**DRI Dashboards** shall display disaster-risk-intelligence indicators, signal records, confidence labels, uncertainty labels, hotspot records, multi-hazard records, cascade records, vulnerability context, exposure context, resilience-capacity context, public-safe intelligence summaries, national DRI contributions, correction records, and archive status within a defined public-safe or controlled scope.

DRI Dashboards shall not issue public warnings, emergency alerts, insurance scores, investment signals, public finance decisions, public authority decisions, official forecasts, procurement signals, or operational commands. Where early-warning, public alerting, or emergency management functions are relevant, DRI Dashboards shall identify public authority dependencies and shall not substitute for competent public authority systems.

### 9.2.3 WFEH-B dashboards.

**WFEH-B Dashboards** shall display water, food, energy, health, biodiversity, and cross-system resilience information, including system dependencies, cascading risks, infrastructure dependencies, climate stressors, nature dependencies, public health context, agricultural context, supply-chain context, national portfolio context, Observatory signals, DRI indicators, and public-safe reporting outputs. They shall support systems literacy, public-good planning, National Portfolio formation, Nexus Universe preparation, and handoff dependency awareness.

WFEH-B Dashboards shall not certify system resilience, issue official health or environmental determinations, create public warnings, rank communities or countries, approve infrastructure, authorize deployment, imply procurement preference, create financeability, create insurability, or grant community or Indigenous consent.

### 9.2.4 Campaign dashboards.

**Campaign Dashboards** shall display campaign purpose, campaign status, public-safe storytelling, volunteer activity, signature activity, pledge activity, support records, team activity, chapter activity, ambassador activity, quest and bounty activity, Working Group formation, Competence Cell formation, Nexus Universe routing, public Reports, Support Ledgers, trust and safety signals, correction records, and archive status.

Campaign Dashboards shall not convert signatures into votes, pledges into binding finance, donor interest into commitment, support into control, volunteer activity into employment, public attention into public authority approval, community participation into consent, sponsor visibility into authority, or campaign momentum into execution authority. They shall include public-safe notices, fraud controls, data minimization, youth safeguards where applicable, and correction channels.

### 9.2.5 Foundry dashboards.

**Foundry Dashboards** shall display programs, tracks, quests, bounties, builds, maintainers, review gates, release classes, micro-production status, evidence outputs, software builds, data builds, dashboard builds, Studio workflow builds, Marketplace object builds, Registry record builds, Grid inputs, TRL evidence builds, Reports builds, Campaign builds, handoff dependency builds, correction loops, and archive status.

Foundry Dashboards shall support public-good production visibility, contributor coordination, quality control, review readiness, and release discipline. They shall not create employment status, procurement qualification, product certification, provider validation, deployment authorization, financeability, insurability, or execution authority.

### 9.2.6 Reports dashboards.

**Reports Dashboards** shall display publication pipelines, Report families, drafting status, review status, public-safe transformation status, repository preparation, DOI metadata where applicable, licensing, data availability statements, AI-use statements, public-safe abstracts, controlled knowledge exclusions, correction notices, withdrawal notices, archive records, and distribution status.

Reports Dashboards shall not make publication equivalent to approval, authority, public warning, official decision, certification, financeability, procurement readiness, country ranking, deployment authorization, or execution. They shall preserve publication lifecycle records, public-safe restrictions, correction pathways, and archive labels.

### 9.2.7 Marketplace dashboards.

**Marketplace Dashboards** shall display object listings, discovery metrics, support requests, reuse signals, download signals where appropriate, translation requests, accessibility requests, bug reports, feature requests, national demand signals, handoff interest signals, provider-neutrality notes, sponsor-boundary notes, procurement-neutrality notes, finance-boundary notes, correction status, delisting status, and archive status.

Marketplace Dashboards shall not create endorsement, featured validation, procurement recommendation, provider approval, sponsor control, finance signal, insurance signal, public authority approval, deployment authorization, or execution authority. Discovery is not approval; listing is not procurement; demand signal is not commitment.

### 9.2.8 Registry dashboards.

**Registry Dashboards** shall display object records, status records, version records, review records, data-use records, AI-use records, support records, provider contribution records, sponsor support records, public authority participation records, correction records, withdrawal records, recall records, archive records, and status truth across DDPGF objects.

Registry Dashboards shall preserve record integrity and lifecycle truth. Registry display shall not create certification, legal approval, public authority status, procurement status, financeability, insurability, deployment authorization, or execution authority. Registry status shall be bounded by recorded scope.

### 9.2.9 Academy dashboards.

**Academy Dashboards** shall display learning objects, pathway progress, ILA records where authorized, WILP activity, micro-credential activity, Risk Academy modules, learner participation records, contribution records, mentor records, assessment status, accessibility status, curriculum review status, AI-use review status, public-safe review status, safeguard review status, correction status, and archive status.

Academy Dashboards shall not create professional licenses, degrees, employment eligibility, immigration status, wage status, procurement qualification, public authority approval, deployment authority, or execution authority. Learning display shall remain privacy-preserving, learner-controlled where applicable, and correctionable.

### 9.2.10 Studio dashboards.

**Studio Dashboards** shall display controlled workflow status, runtime status, digital twin status, simulation status, scenario status, AI workflow review status, data-room workflow status, secure-room workflow status, public authority learning-room status, readiness-room status, output review status, access activity, shutdown triggers, correction triggers, and archive status.

Studio Dashboards shall not become operational command surfaces. They shall not create public authority decisions, AI determinations, deployment authorization, finance approval, insurance underwriting, procurement status, consent, or execution authority. Studio dashboards shall preserve no-write-back, no-command, output review, and controlled export rules.

### 9.2.11 Grid dashboards.

**Grid Dashboards** shall display maturity-input status, review-routing status, evidence sufficiency, method sufficiency, data sufficiency, AI-use sufficiency, cyber sufficiency, public-safe sufficiency, safeguard sufficiency, support sufficiency, reproducibility sufficiency, correction sufficiency, readiness classes, review gates, downgrades, suspensions, withdrawals, reinstatements, and archive status.

Grid Dashboards shall not certify maturity, certify quality, create procurement readiness, create financeability, create insurability, create public authority approval, authorize deployment, or create execution authority. They shall display bounded evidence memory, not approval.

### 9.2.12 Handoff dependency dashboards.

**Handoff Dependency Dashboards** shall display handoff package status, evidence context, data context, method context, Studio context, Grid and TRL context, public-safe status, safeguard status, public authority dependencies, legal dependencies, finance and insurance questions, procurement boundaries, provider-neutrality notes, sponsor-boundary notes, recipient responsibilities, correction pathways, recall pathways, and archive status.

Handoff Dependency Dashboards shall support lawful downstream awareness, not execution. Handoff context is not authorization; readiness is not finance; evidence is not approval; recipient responsibility remains separate; and handoff can be corrected, recalled, restricted, or archived.

## 9.3 Digital Twin and Simulation Classes

### 9.3.1 Conceptual twin.

A **Conceptual Twin** is a non-operational representation of a system’s structure, relationships, dependencies, actors, flows, failure modes, or governance logic. It may be expressed through diagrams, system maps, causal maps, ontology-linked maps, risk maps, dependency maps, or explanatory models. Conceptual Twins are useful for early-stage learning, problem framing, scenario design, National Portfolio formation, Academy teaching, public authority learning, Foundry scoping, and Reports.

A Conceptual Twin shall not be treated as operational truth, real-time status, official map, deployment basis, public authority decision, finance evidence, insurance evidence, procurement evidence, or execution authorization.

### 9.3.2 Data-linked twin.

A **Data-Linked Twin** is a digital twin connected to datasets, metadata, indicators, signals, dashboards, APIs, Observatory inputs, DRI records, National Portfolio records, or other data sources. It may update periodically or dynamically depending on source availability and governance. A Data-Linked Twin shall record source systems, data quality, lineage, update cadence, missingness, uncertainty, sensitivity labels, public-safe transformations, and correction pathways.

A Data-Linked Twin shall not imply complete reality, official measurement, unrestricted data rights, public authority action, forecast certainty, deployment readiness, financeability, insurability, procurement readiness, or execution authority.

### 9.3.3 Scenario twin.

A **Scenario Twin** is a twin used to explore alternative possible futures, interventions, hazards, disruptions, system stresses, cascading effects, technology pathways, policy questions, public authority learning questions, readiness questions, finance-readiness questions, or safeguard questions. Scenario Twins may support tabletop exercises, Nexus Studio workflows, Risk Academy modules, DRI exploration, Nexus Universe demonstrations, and handoff dependency analysis.

A Scenario Twin shall preserve assumption records, scenario framing, limitations, uncertainty labels, confidence labels, and no-forecast-certainty notices. It shall not issue warnings, predictions, ratings, operational instructions, official decisions, or deployment authority.

### 9.3.4 Infrastructure twin.

An **Infrastructure Twin** is a governed representation of physical, digital, network, energy, water, transport, telecom, edge, cloud, HPC, data, sensor, OT, IoT, IIoT, or cyber-physical infrastructure within a recorded public-good purpose. Infrastructure Twins may support resilience learning, dependency mapping, degraded-mode awareness, secure-room analysis, public authority learning, readiness discussion, and handoff context.

Infrastructure Twins shall apply critical infrastructure sensitivity controls, cyber-sensitive controls, geospatial masking, access restriction, public-safe output review, and no-command rules. They shall not expose operational vulnerabilities, create emergency command, approve infrastructure, authorize deployment, create procurement preference, or validate providers.

### 9.3.5 WFEH-B twin.

A **WFEH-B Twin** is a digital twin or simulation object representing water, food, energy, health, biodiversity, nature, and cross-system interactions within a defined geography, corridor, cluster, national portfolio, regional portfolio, or thematic scope. It may help examine dependency chains, cascading risk, resilience capacity, climate stress, disaster risk, infrastructure stress, public health context, nature dependencies, or handoff requirements.

A WFEH-B Twin shall not certify resilience, issue public warnings, approve projects, rank communities, authorize interventions, create public authority decisions, create financeability, create insurability, or grant community or Indigenous consent.

### 9.3.6 Disaster-risk twin.

A **Disaster-Risk Twin** is a governed twin or simulation object used to explore hazard exposure, vulnerability, resilience capacity, multi-hazard interactions, cascading effects, preparedness gaps, risk-reduction options, risk-finance questions, disaster-risk-intelligence needs, early-warning dependencies, and public-safe reporting needs. It may be linked to DRI, Observatory, Reports, Studio, Academy, Foundry, Grid, TRL, and Nexus Universe workflows.

A Disaster-Risk Twin shall not issue warnings, emergency alerts, evacuation instructions, official forecasts, public authority decisions, insurance scores, investment signals, or operational commands. Where warning systems are implicated, the twin shall identify public authority dependencies and maintain no-warning status.

### 9.3.7 Sensor-linked twin.

A **Sensor-Linked Twin** is a twin connected to sensor networks, edge devices, IoT systems, OT systems, IIoT systems, geospatial feeds, Earth observation sources, telemetry streams, or Observatory nodes. Sensor-linked operation shall require source validation, latency notes, data quality notes, calibration notes where applicable, missingness notes, cyber controls, privacy controls, sensitive-location controls, degraded-mode awareness, and output review.

A Sensor-Linked Twin shall not become a surveillance system by implication, an operational command system, a public authority system, a public warning system, or a deployment control system unless separately authorized outside DDPGF by competent lawful actors.

### 9.3.8 Public authority learning twin.

A **Public Authority Learning Twin** is a controlled twin used in a public authority learning posture to explore policy questions, regulatory questions, emergency planning questions, infrastructure dependency questions, resilience questions, technology governance questions, disaster-risk questions, WFEH-B questions, public finance relevance questions, or implementation dependencies. Public authority participation in such a twin shall be recorded as learning, not action.

A Public Authority Learning Twin shall not create public authority approval, decision, adoption, enforcement, official warning, official map, public finance allocation, procurement status, permit, license, approval, command, or implementation authorization.

### 9.3.9 Readiness-room twin.

A **Readiness-Room Twin** is a controlled twin used to examine evidence, assumptions, dependencies, safeguards, technical readiness, data readiness, AI readiness, cyber readiness, public-safe readiness, finance-readiness questions, insurance-readiness questions, procurement boundaries, and handoff dependencies. It may be used by reviewers, capital readers, insurance readers, donors, public finance readers, public authority learning participants, National Nodes, National Companies, Project SPVs, or other lawful downstream recipients.

A Readiness-Room Twin shall not create readiness certification, finance approval, insurance underwriting, donor commitment, public finance allocation, procurement approval, public authority approval, deployment authorization, or execution authority.

### 9.3.10 Handoff-context twin.

A **Handoff-Context Twin** is a twin prepared to help lawful downstream recipients understand evidence context, data context, method context, dependency context, public authority dependencies, legal dependencies, safeguard dependencies, finance and insurance questions, procurement boundaries, provider-neutrality notes, sponsor-boundary notes, and correction pathways. It supports transfer of context and dependencies from public-good stack to enterprise or lawful implementation contexts.

A Handoff-Context Twin shall not transfer authority. It shall not authorize execution, procurement, finance, insurance, deployment, public authority action, provider selection, operational command, or consent. Handoff recipients remain responsible for independent diligence and lawful action.

## 9.4 Runtime Controls

### 9.4.1 Access control.

Runtime Objects shall apply access controls appropriate to their sensitivity, purpose, data class, AI-use label, public-safe status, safeguard status, room type, support class, and handoff relevance. Access may be public, controlled public, internal, secure-room-only, data-room-only, protected-knowledge-room-only, public authority learning-room-only, readiness-room-only, capital-reader-room-only, insurance-reader-room-only, donor-reader-room-only, Studio-only, National Node-only, handoff-recipient-only, or archive-only.

Access control shall prevent unauthorized viewing, downloading, exporting, copying, inference, scraping, re-identification, sensitive-location exposure, protected knowledge exposure, public authority overclaim, finance overclaim, procurement overclaim, and execution overclaim. Access shall not create rights beyond the recorded scope.

### 9.4.2 Role-based permissions.

Runtime Objects shall assign permissions based on recorded roles, including viewer, learner, contributor, reviewer, maintainer, steward, public-safe reviewer, data steward, AI reviewer, cyber reviewer, safeguard reviewer, public authority learning participant, capital reader, insurance reader, donor reader, National Node participant, handoff recipient, administrator, archive steward, and correction steward. Permissions shall distinguish viewing, commenting, annotating, running a scenario, modifying assumptions, changing source data, exporting outputs, approving within scope, updating Registry status, listing Marketplace objects, generating Reports, and initiating correction.

Role-based permissions shall not collapse into authority by role title. No participant shall gain public authority, finance, insurance, procurement, consent, deployment, operational command, or execution authority merely by holding a runtime role.

### 9.4.3 No-write-back rule.

Runtime Objects shall default to a **no-write-back rule**, meaning that dashboards, digital twins, simulations, Studio workflows, AI workflows, or scenario environments shall not directly write back to source systems, physical systems, operational systems, public authority systems, emergency systems, finance systems, insurance systems, procurement systems, community records, protected knowledge repositories, or enterprise execution systems unless separately authorized, logged, reviewed, and governed.

Where write-back is technically necessary for controlled internal workflow purposes, it shall be limited to authorized DDPGF records, workflow states, audit logs, correction records, Registry status updates, Marketplace listing states, or archive states within recorded governance. Write-back shall never be used to bypass review, create hidden decisions, alter evidence silently, or execute downstream activity.

### 9.4.4 No-command rule.

Runtime Objects shall default to a **no-command rule**, meaning they shall not issue commands to infrastructure, sensors, drones, robotics, OT systems, IoT systems, IIoT systems, telecom systems, AI agents with external tool authority, emergency systems, public authority systems, finance systems, insurance systems, procurement systems, health systems, or operational systems. They may simulate, display, interpret, review, or prepare handoff context, but they shall not control operational reality.

Any command-capable exception shall sit outside the default DDPGF posture and shall require separate lawful authority, security governance, operational governance, public authority dependency review, cyber review, AI review where applicable, safeguard review, logging, incident response, and explicit separation from public-good object governance.

### 9.4.5 Output review.

Runtime Object outputs shall be reviewed before public release, external distribution, Registry update, Marketplace listing, Report publication, Grid input, TRL note, public authority learning-room release, capital-reader-room release, insurance-reader-room release, donor-reader-room release, or handoff package inclusion where the output contains sensitive, uncertain, AI-generated, model-generated, simulated, geospatial, public authority-sensitive, finance-sensitive, insurance-sensitive, procurement-sensitive, community-sensitive, Indigenous protocol-sensitive, health-sensitive, cyber-sensitive, infrastructure-sensitive, or protected knowledge content.

Output review shall assess source validity, method sufficiency, assumptions, limitations, uncertainty, confidence, public-safe language, boundary notices, sensitive data exposure, protected knowledge exposure, visual overclaim, warning overclaim, rating overclaim, finance overclaim, procurement overclaim, certification overclaim, consent overclaim, and execution overclaim.

### 9.4.6 Logging.

Runtime Objects shall maintain logs appropriate to their sensitivity and purpose, including access logs, query logs, scenario-run logs, model-run logs, parameter-change logs, export logs, output-review logs, permission-change logs, correction logs, shutdown logs, and archive logs. Logging shall support accountability, provenance, security, incident response, correctionability, and institutional memory.

Logging shall be privacy-preserving and proportionate. It shall not be used for unauthorized surveillance, worker ranking, learner ranking, community profiling, social scoring, public authority enforcement, finance scoring, insurance scoring, procurement scoring, or unauthorized behavioral analytics.

### 9.4.7 Data export restrictions.

Runtime Objects shall restrict data export according to data class, room type, source rights, sensitivity, public-safe status, AI-use labels, data-use labels, protected knowledge controls, jurisdictional requirements, public authority dependencies, and handoff conditions. Exports may be prohibited, metadata-only, public-safe summary only, aggregated only, redacted only, delayed, watermarked, logged, reviewer-approved, handoff-recipient-only, or archive-only.

Export permission shall not create unrestricted reuse rights, AI-training rights, publication rights, data transfer rights, public authority approval, procurement status, finance status, insurance status, deployment authorization, or execution authority.

### 9.4.8 Public-safe restrictions.

Runtime Objects shall apply public-safe restrictions to prevent release of harmful, misleading, overclaiming, sensitive, unsafe, or unauthorized outputs. Restrictions shall include no-warning language, no-approval language, no-finance language, no-procurement language, no-certification language, no-consent language, no-deployment language, no-execution language, uncertainty labeling, confidence labeling, source notes, sensitive location masking, protected knowledge removal, and public repair notices where applicable.

Public-safe restrictions shall apply especially to DRI dashboards, Observatory dashboards, disaster-risk twins, WFEH-B twins, infrastructure twins, sensor-linked twins, AI workflows, public authority learning-room outputs, readiness-room outputs, capital-reader-room outputs, insurance-reader-room outputs, Reports, Marketplace listings, and handoff packages.

### 9.4.9 Shutdown triggers.

Runtime Objects shall include shutdown or suspension triggers where continued operation may create risk. Triggers may include data breach, privacy incident, cyber incident, protected knowledge exposure, public-safe incident, false warning risk, AI incident, model drift, sensitive location exposure, unauthorized export, public authority overclaim, finance overclaim, procurement overclaim, provider validation overclaim, sponsor control overclaim, consent overclaim, handoff overclaim, execution overclaim, dependency failure, source withdrawal, legal hold, or material correction requirement.

Shutdown may include immediate containment, access suspension, claims freeze, data freeze, technical freeze, model freeze, API freeze, Marketplace delisting, Registry status update, public-safe notice, handoff recall, correction review, archive, or reinstatement after review.

### 9.4.10 Archive rules.

Runtime Objects shall have archive rules defining when a dashboard, visual atlas, digital twin, simulation, scenario, Studio workflow, dataset connection, model connection, API connection, Registry view, Marketplace view, or handoff view is preserved, deprecated, superseded, withdrawn, recalled, sealed, restricted, or marked non-continuing. Archive records shall include object identity, version, source basis, public-safe status, support status, correction history, successor links, access class, retention rule, and archive-not-current notice.

Archived Runtime Objects shall not be treated as current evidence, current dashboard truth, current scenario basis, current digital twin status, current Registry status, current Marketplace listing, current Grid input, current TRL context, current public authority learning context, or current handoff context unless separately reinstated by review.

## 9.5 Visualization Governance

### 9.5.1 Source notes.

Every visual object shall include source notes sufficient to identify the data, metadata, model, method, Report, Registry record, Marketplace object, DRI record, Observatory record, Studio workflow, Grid input, TRL note, National Portfolio object, Campaign object, Foundry object, Academy object, or handoff object on which the visual display relies. Source notes shall distinguish primary sources, derived sources, modeled sources, simulated sources, public-safe summaries, controlled sources, and archive sources.

Source notes shall support transparency without exposing restricted, confidential, protected, cyber-sensitive, infrastructure-sensitive, health-sensitive, public authority-sensitive, community-sensitive, Indigenous protocol-sensitive, or geospatial-sensitive source material.

### 9.5.2 Confidence labels.

Visual objects shall include confidence labels where interpretation depends on data quality, model quality, source reliability, update cadence, method maturity, evidence sufficiency, review status, scenario framing, DRI indicator maturity, Observatory signal strength, or simulation quality. Confidence labels shall be bounded to the displayed scope and shall not imply general validity, certification, rating, approval, financeability, insurability, procurement readiness, or operational readiness.

Confidence labels shall be corrected where new evidence, source changes, model changes, data quality issues, public-safe issues, or review outcomes require adjustment.

### 9.5.3 Uncertainty labels.

Visual objects shall display uncertainty where data are incomplete, stale, modeled, inferred, simulated, scenario-based, contested, low-resolution, aggregated, masked, delayed, public-safe transformed, or subject to material limitations. Uncertainty labels shall prevent false precision and visual overclaim.

Uncertainty shall not be hidden to make outputs appear more decisive. A visual object that cannot display uncertainty responsibly shall be restricted, redesigned, or withheld from public-safe release.

### 9.5.4 Update cadence.

Visual objects shall identify update cadence, including real-time, near-real-time, daily, weekly, monthly, quarterly, annual, event-based, manual, archive-only, static, or not-current status. Update cadence shall include last updated date where appropriate and shall indicate whether source data, model assumptions, Registry status, Marketplace listing status, DRI indicators, Observatory signals, Studio workflows, Grid inputs, TRL notes, or handoff dependencies may have changed.

A visual object shall not imply current status where it is historical, static, delayed, archived, or unsupported.

### 9.5.5 Public-safe disclaimers.

Public-safe visual objects shall include boundary notices appropriate to the object class. These may include: visualization is not a decision; dashboard is not public authority action; DRI display is not public warning; indicator is not rating; scenario is not forecast certainty; digital twin is not operational command; Registry status is not certification; Marketplace listing is not procurement; readiness display is not financeability; Studio workflow is not deployment; community participation is not consent; and handoff context is not authorization.

Disclaimers shall be specific, visible, and tied to the relevant overclaim risk. They shall not be generic decorative text.

### 9.5.6 Sensitive location masking.

Visual objects shall apply sensitive location masking where displaying exact or high-resolution locations may expose critical infrastructure, protected species, sacred sites, protected knowledge, community-sensitive sites, Indigenous protocol-sensitive sites where applicable, cyber-sensitive infrastructure, health-sensitive facilities, emergency assets, data centers, telecom assets, energy assets, water assets, food system assets, public authority-sensitive sites, or vulnerable populations.

Masking may include aggregation, generalization, blurring, displacement, delay, resolution reduction, access restriction, secure-room-only display, or removal. Masked visuals shall avoid creating misleading precision or false absence.

### 9.5.7 Accessibility review.

Visual objects shall undergo accessibility review appropriate to their audience and release class. Accessibility review may include screen-reader compatibility, alt text, captions, keyboard navigation, color-contrast review, non-color-dependent coding, plain-language summaries, multilingual metadata, low-bandwidth formats, mobile-first display, downloadable public-safe alternatives, and disability inclusion review.

Accessibility shall be treated as a public-good quality requirement, not an optional presentation feature. Where accessibility cannot be fully achieved, limitations and alternative formats shall be recorded.

### 9.5.8 Localization.

Visual objects shall be localizable for national, regional, linguistic, legal, public authority, cultural, accessibility, low-bandwidth, and community contexts. Localization may include translation, terminology mapping, units conversion, jurisdictional notes, public authority terminology notes, national data-context notes, cultural context review, community-safe framing, and national ownership controls.

Localization shall not alter substantive meaning without review. Translation or localization shall not constitute public authority adoption, community approval, Indigenous consent, legal equivalence, standards adoption, procurement approval, or official national position by implication.

### 9.5.9 Correction notices.

Visual objects shall include correction notices where errors, changes, supersessions, withdrawals, recalls, downgrades, suspensions, data-quality issues, model issues, public-safe issues, sensitivity issues, or boundary issues affect interpretation. Correction notices shall identify what changed, why it changed where appropriate, the affected version, the correction date, the successor object where applicable, and the current status.

Correction notices shall be propagated to dependent dashboards, atlases, twins, simulations, scenarios, Studio workflows, Reports, Registry records, Marketplace listings, Grid inputs, TRL notes, National Portfolio objects, Nexus Universe outputs, and handoff packages where relevant.

### 9.5.10 Archive labels.

Archived visual objects shall be clearly labeled as archived, historical, superseded, withdrawn, recalled, unsupported, deprecated, non-continuing, or not-current, as applicable. Archive labels shall identify archive date, current-use limits, successor link where applicable, correction history, public-safe status, access class, and retention rule.

Archived visual objects shall not be displayed in a manner that suggests current status, current decision support, current risk intelligence, current public authority learning status, current readiness, current Registry truth, current Marketplace listing, current handoff context, or current operational relevance unless separately reinstated.

## 9.6 Dashboard and Digital Twin Boundary Rules

### 9.6.1 Dashboard is not decision.

A Dashboard Object may support learning, awareness, review, evidence interpretation, public-safe communication, DRI understanding, Observatory visibility, portfolio governance, Registry status display, Marketplace discovery, Studio workflow monitoring, Grid review, TRL context, Nexus Universe preparation, and handoff dependency awareness. It shall not be treated as a decision, official action, public authority determination, procurement determination, finance determination, insurance determination, consent determination, deployment determination, or execution authorization.

### 9.6.2 Digital twin is not operational control.

A Digital Twin Object may represent, simulate, explore, or explain aspects of a system within recorded limitations. It shall not control the represented system, command infrastructure, direct public authority action, trigger emergency operations, approve interventions, authorize deployment, validate providers, select vendors, create financeability, create insurability, or execute projects by implication.

### 9.6.3 Simulation is not forecast certainty.

A Simulation Object may examine possible behavior under assumptions and scenarios, but it shall not be represented as forecast certainty, probability certainty, official prediction, warning, emergency instruction, investment signal, insurance signal, procurement signal, certification, approval, deployment authorization, or operational command. Simulation outputs shall preserve assumptions, limitations, uncertainty, confidence, and correction pathways.

### 9.6.4 Scenario is not public warning.

A Scenario Object may describe possible future conditions, risks, cascades, hazards, failures, opportunities, dependencies, or learning questions, but it shall not issue a public warning, emergency alert, official forecast, evacuation instruction, regulatory determination, public authority decision, insurance score, investment signal, procurement signal, or execution instruction. Public warning functions remain outside DDPGF and belong to competent public authorities or authorized systems.

### 9.6.5 Studio object is not deployment authorization.

A Studio Workflow Object may support controlled demonstration, simulation, AI workflow review, secure-room analysis, data-room review, public authority learning, readiness-room discussion, capital-reader-room literacy, insurance-reader-room literacy, Nexus Universe demonstration, or handoff-context preparation. It shall not authorize production deployment, field deployment, operational use, public authority action, finance approval, underwriting, procurement, consent, or execution.

### 9.6.6 Visual display is not rating or ranking by default.

A visual display, dashboard order, map color, score, indicator, status label, readiness label, Registry view, Marketplace view, Grid view, TRL view, DRI view, Observatory view, or National Portfolio visualization shall not be interpreted as a rating, ranking, certification, country ranking, provider ranking, community ranking, finance score, insurance score, procurement score, maturity certification, public authority grade, or investment signal unless a separately authorized and recorded process expressly creates such meaning. By default, DDPGF visual objects are learning, evidence, discovery, public-safe interpretation, and correction surfaces, not rating or ranking systems.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.therisk.global/organization/operations/frameworks/distributed-digital-public-goods-framework-ddpgf/ix.-runtime.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.