# XIV. STUDIO

## 14.1 Controlled Runtime Doctrine

### 14.1.1 Studio as controlled workflow environment.

The **Nexus Studio** under the Distributed Digital Public Goods Framework shall function as a controlled workflow environment for the preparation, review, demonstration, simulation, transformation, interpretation, and public-safe release of digital-public-good objects where ordinary publication, ordinary repository access, or ordinary open reuse would be insufficient, unsafe, premature, restricted, or boundary-sensitive. Nexus Studio may support dashboards, digital twins, simulations, AI workflows, data workflows, model review, secure-room workflows, public authority learning workflows, readiness workflows, public-safe output workflows, Nexus Universe demonstrations, National Portfolio preparation, Foundry builds, DICE workflows, GRIx workflows, DRI workflows, Observatory workflows, Grid inputs, TRL notes, Marketplace listings, Registry records, Reports preparation, and lawful handoff context.

Nexus Studio shall be a workflow and learning environment, not an execution authority. It may enable controlled interaction with objects, evidence, methods, data, models, dashboards, scenarios, and dependency packages, but it shall not authorize public authority decisions, operational command, deployment, procurement, finance, insurance, underwriting, community consent, Indigenous consent, provider validation, certification, or enterprise execution by implication.

### 14.1.2 Secure room defined.

A **Secure Room** means a controlled digital, physical, hybrid, or procedural environment designed to restrict access to sensitive DDPGF objects, workflows, records, datasets, models, technical materials, cyber-sensitive information, infrastructure-sensitive information, public authority-sensitive materials, protected knowledge, restricted handoff packages, or other high-risk objects. A Secure Room shall use role-based access, purpose limitation, identity verification, logging, audit trails, no-download rules where required, output review, confidentiality controls, incident response procedures, and archive rules appropriate to the object class and sensitivity.

A Secure Room shall not create approval, certification, data rights, public authority status, handoff permission, deployment authorization, procurement status, financeability, insurability, or execution authority. Secure Room access means controlled review or controlled participation only within the recorded scope.

### 14.1.3 Data room defined.

A **Data Room** means a controlled environment for viewing, reviewing, analyzing, validating, documenting, or preparing data objects, metadata records, data papers, data availability statements, benchmark datasets, public-safe datasets, controlled datasets, DRI datasets, Observatory datasets, National Portfolio datasets, or handoff data context. A Data Room may be open, controlled, restricted, secure, no-download, compute-to-data-enabled, public authority learning-oriented, readiness-oriented, capital-reader-oriented, insurance-reader-oriented, donor-reader-oriented, or handoff-recipient-oriented, depending on data classification.

Data Room access shall not create a data right, reuse permission, AI training permission, cross-border transfer permission, protected knowledge permission, community consent, Indigenous consent, public authority approval, handoff permission, procurement status, financeability, or deployment authorization. Data Room outputs shall be reviewed before release, export, citation, publication, Marketplace listing, Registry update, Report inclusion, or handoff packaging.

### 14.1.4 Clean room defined.

A **Clean Room** means a controlled environment in which one or more approved users, institutions, datasets, models, or workflows may interact under rules designed to prevent unauthorized raw-data disclosure, unauthorized data combination, re-identification, leakage, intellectual-property misuse, protected knowledge exposure, or unsafe output release. Clean Rooms may support privacy-preserving analytics, federated analysis, benchmarking, model evaluation, public-safe transformation, controlled collaboration, multi-party research, public authority learning, readiness review, or handoff-context preparation.

A Clean Room shall preserve separation between access, analysis, output, and authority. Clean Room participation shall not imply that participants own, approve, endorse, validate, certify, finance, insure, procure, deploy, or execute the object being reviewed.

### 14.1.5 Compute-to-data defined.

**Compute-to-Data** means a controlled workflow pattern in which approved computation is brought to restricted, sensitive, sovereign, protected, or controlled data rather than exporting raw data to users or external environments. Compute-to-Data may apply to public authority-sensitive data, community-sensitive data, Indigenous protocol-sensitive data where applicable, protected knowledge, health-sensitive data, youth data, cyber-sensitive data, infrastructure-sensitive data, geospatial-sensitive data, Observatory data, DRI data, National Portfolio data, controlled research data, or handoff-recipient-only data.

Compute-to-Data shall use approved workloads, approved users, query controls, execution logging, output review, privacy-preserving methods where appropriate, confidential computing where appropriate, secure enclaves where appropriate, no raw data extraction, retention controls, and incident response. Compute-to-Data shall not convert restricted data into open data, nor shall it create data ownership, reuse rights, public authority record status, consent, handoff permission, deployment authority, or execution authority.

### 14.1.6 Protected knowledge room defined.

A **Protected Knowledge Room** means a controlled room for knowledge that is culturally sensitive, community-sensitive, Indigenous protocol-sensitive, ecological-sensitive, security-sensitive, cyber-sensitive, infrastructure-sensitive, location-sensitive, health-sensitive, youth-sensitive, legally restricted, confidential, or otherwise unsuitable for ordinary public access. Protected Knowledge Rooms may support respectful review, public-safe transformation, community safeguard review, Indigenous protocol review where applicable, rights review, sensitivity review, archive review, or limited handoff-context preparation.

Protected Knowledge Room access shall be exceptional, purpose-limited, safeguarded, and recorded. It shall not grant permission to disclose, publish, commercialize, train AI systems on, translate, reuse, operationalize, procure, finance, insure, deploy, or execute based on protected knowledge unless a separate lawful and protocol-compliant permission process is completed and recorded.

### 14.1.7 Runtime without decision authority.

A controlled runtime environment may support interaction, analysis, simulation, review, training, demonstration, public authority learning, readiness questioning, capital-readable discussion, insurance-readable discussion, donor-readable discussion, and handoff-context preparation, but it shall not make decisions. No Nexus Studio workflow, Secure Room, Data Room, Clean Room, Protected Knowledge Room, AI Review Room, Cyber Review Room, Readiness Room, Capital-Reader Room, Insurance-Reader Room, Donor-Reader Room, Public Authority Learning Room, or Community Safeguard Room shall be treated as a decision-making body by default.

Outputs from controlled runtime environments shall be records, not determinations. Any public authority decision, procurement decision, investment decision, underwriting decision, donor allocation, community consent, Indigenous consent, deployment decision, operational command, or enterprise execution shall occur separately through competent actors, lawful processes, and recorded authority outside the default DDPGF runtime posture.

### 14.1.8 Demonstration without deployment authority.

Nexus Studio and controlled rooms may demonstrate software, dashboards, digital twins, simulations, models, AI workflows, APIs, data workflows, public-safe outputs, National Portfolio objects, Grid inputs, TRL notes, Nexus Universe objects, and handoff-context packages. Demonstration shall be used for learning, review, understanding, evidence formation, public-safe explanation, readiness questioning, and controlled evaluation.

A demonstration shall not constitute deployment, operational use, production approval, public authority approval, procurement approval, safety certification, provider validation, financeability, insurability, community consent, Indigenous consent, or execution authorization. Demonstration language, screens, metadata, reports, and recordings shall carry appropriate boundary notices and shall not imply that an object is ready for real-world use beyond its recorded scope.

## 14.2 Room Classes

### 14.2.1 Public authority learning room.

A **Public Authority Learning Room** shall support non-decisional learning by public authorities, regulators, ministries, agencies, local governments, emergency management bodies, public finance readers, public procurement observers, or other public bodies. It may present evidence, dashboards, simulations, DRI outputs, Observatory outputs, National Portfolio objects, public-safe Reports, Studio workflows, digital twins, AI-use examples, data governance patterns, or handoff dependencies for learning and literacy.

A Public Authority Learning Room shall not create public authority action, policy adoption, regulatory guidance, compliance determination, permit, license, approval, public warning, emergency command, public finance allocation, procurement decision, or governmental endorsement. Attendance, observation, questions, comments, or participation shall be recorded only as learning participation unless a competent public authority separately records official action through its own process.

### 14.2.2 Readiness room.

A **Readiness Room** shall support structured review of evidence, dependencies, assumptions, safeguards, technical maturity, data status, AI-use status, cyber status, public-safe status, support status, Grid inputs, TRL notes, finance-readiness questions, insurance-readiness questions, public authority dependencies, procurement boundaries, and handoff-context requirements. Readiness Rooms may support National Portfolios, Foundry outputs, Studio workflows, Reports, Marketplace objects, Registry records, Nexus Universe outputs, or lawful handoff packages.

A Readiness Room shall not create approval, certification, maturity certification, finance approval, insurance approval, procurement readiness, deployment authorization, or execution authority. Readiness means recorded questions, evidence, sufficiency, gaps, and dependencies, not authorization.

### 14.2.3 Capital-reader room.

A **Capital-Reader Room** shall allow capital readers, financial-literacy participants, development finance observers, philanthropic capital observers, banks, investors, analysts, or no-reliance finance-readiness participants to read structured readiness context, assumptions, dependencies, risk notes, evidence records, diligence-gap registers, National Portfolio context, and handoff-context materials. Capital-Reader Rooms shall be no-reliance, non-soliciting, non-transactional, competition-compliant, confidentiality-aware, and regulated-perimeter controlled.

A Capital-Reader Room shall not constitute investment activity, securities offering, solicitation, investment advice, finance advice, transaction room, bankability determination, credit approval, guarantee, investor commitment, donor commitment, public finance allocation, or financeability determination. Capital readers read; they do not control public-good priorities or create finance by presence.

### 14.2.4 Insurance-reader room.

An **Insurance-Reader Room** shall allow insurers, reinsurers, risk-finance actors, protection-gap analysts, resilience finance observers, or insurance-literacy participants to review insurance-readiness questions, exposure context, vulnerability context, DRI records, assumptions, data limitations, evidence notes, risk-layering questions, loss-model dependencies, public authority dependencies, and handoff-context materials. Insurance-Reader Rooms shall be no-reliance, non-underwriting, non-binding, confidentiality-aware, and regulated-perimeter controlled.

An Insurance-Reader Room shall not constitute underwriting, insurance advice, pricing, binding authority, coverage approval, claim determination, insurance score, insurability determination, risk transfer commitment, guarantee, or regulated insurance activity by default.

### 14.2.5 Donor-reader room.

A **Donor-Reader Room** shall allow donors, foundations, philanthropies, development actors, humanitarian funders, and grant-readiness observers to review public-good needs, National Portfolio context, Campaign records, Reports, evidence packs, support needs, readiness questions, safeguard dependencies, implementation dependencies, and handoff-context materials. Donor-Reader Rooms shall be non-binding, no-reliance, non-allocative, and public-good disciplined.

A Donor-Reader Room shall not create donor commitment, grant allocation, funding approval, financeability, public authority approval, procurement authority, program endorsement, or execution authorization. Donor interest shall remain a support signal only unless separately and lawfully committed.

### 14.2.6 Data room.

A **Data Room** shall support controlled viewing, analysis, documentation, or review of data objects and data-related evidence. Data Rooms may include public-safe data rooms, controlled data rooms, secure data rooms, metadata rooms, data-paper review rooms, National Portfolio data rooms, DRI data rooms, Observatory data rooms, handoff data rooms, or compute-to-data rooms.

Data Rooms shall be governed by access class, data-use label, AI-use label, rights basis, sensitivity class, output review, logging, retention, and correction rules. Data Room access shall not create data rights or handoff permission.

### 14.2.7 Secure room.

A **Secure Room** shall support high-sensitivity review, controlled collaboration, or restricted access for objects requiring enhanced security controls. Secure Rooms may involve cyber-sensitive materials, infrastructure-sensitive materials, security-sensitive code, restricted models, protected knowledge, public authority-sensitive records, confidential partner materials, legal-sensitive records, or handoff-recipient-only packages.

Secure Rooms shall apply heightened identity, access, logging, audit, no-download, output review, incident response, sealing, retention, and archive controls. Secure Room participation shall not create authority, certification, approval, or execution rights.

### 14.2.8 Clean room.

A **Clean Room** shall support controlled analysis across one or more datasets, institutions, models, or parties while preventing unauthorized data disclosure, uncontrolled combination, leakage, re-identification, or unsafe output. Clean Rooms may support privacy-preserving analytics, benchmark evaluation, joint research, model evaluation, federated analysis, or public-safe transformation.

Clean Room outputs shall be reviewed before export or publication. Clean Room participation shall not create permission to access raw data, reuse restricted data, train AI systems, or rely on outputs beyond scope.

### 14.2.9 Protected knowledge room.

A **Protected Knowledge Room** shall support access to sensitive knowledge only under recorded safeguards, permissions, protocols, and review controls. It may be used for protected knowledge review, public-safe summary preparation, community safeguard review, Indigenous protocol review where applicable, ecological sensitivity review, location sensitivity review, or archive handling.

Protected Knowledge Rooms shall not permit extraction, disclosure, publication, AI training, commercial use, operational use, or handoff use unless separately authorized through lawful and protocol-compliant records.

### 14.2.10 AI review room.

An **AI Review Room** shall support controlled review of AI systems, model cards, system cards, benchmark cards, agentic workflows, AI-use labels, training data constraints, evaluation records, prompt-injection risks, tool permissions, output review, bias and harm review, drift concerns, incident records, and model withdrawal conditions. AI Review Rooms may be linked to Studio workflows, Grid inputs, TRL notes, Reports, Registry records, Marketplace listings, and handoff packages.

An AI Review Room shall not create AI safety certification, automated decision authority, deployment approval, public authority approval, procurement readiness, financeability, insurability, or general validation.

### 14.2.11 Cyber review room.

A **Cyber Review Room** shall support controlled review of cybersecurity-sensitive objects, software releases, infrastructure-as-code, APIs, dependencies, SBOMs, vulnerability reports, threat models, network records, OT/IoT sensitivity, edge environments, secure repositories, incident records, and public-safe technical disclosure. Cyber Review Rooms may restrict screenshots, downloads, copy-paste, export, and external communication where required.

Cyber Review Room participation shall not create security certification, vulnerability-free representation, deployment authorization, procurement approval, public authority approval, or operational command authority.

### 14.2.12 Community safeguard room.

A **Community Safeguard Room** shall support controlled, non-extractive, rights-respecting review of community-sensitive, place-based, public-interest, humanitarian, accessibility, disability inclusion, youth, Indigenous protocol-sensitive where applicable, environmental justice, public health, protected knowledge, or local-risk materials. It may support public-safe summaries, community guides, Campaign materials, National Portfolio records, Observatory outputs, WFEH-B materials, or handoff-context review.

Community Safeguard Room participation shall not imply community consent, Indigenous consent, social license, endorsement, approval, permission to implement, permission to use protected knowledge, or authority to act in a community context. Consent, where applicable, must be separately and lawfully recorded.

## 14.3 Runtime Workflow Classes

### 14.3.1 Dashboard workflow.

A **Dashboard Workflow** shall support controlled creation, review, interpretation, update, or demonstration of dashboard objects, including National Portfolio dashboards, DRI dashboards, WFEH-B dashboards, Campaign dashboards, Foundry dashboards, Reports dashboards, Marketplace dashboards, Registry dashboards, Academy dashboards, Studio dashboards, Grid dashboards, Observatory dashboards, and handoff dependency dashboards. Dashboard workflows shall record data basis, update cadence, source notes, confidence labels where applicable, uncertainty labels where applicable, public-safe status, sensitivity controls, accessibility review, and correction path.

A Dashboard Workflow shall not produce public authority decisions, warnings, ratings, rankings, operational commands, finance signals, insurance signals, procurement recommendations, or deployment authorizations.

### 14.3.2 Digital twin workflow.

A **Digital Twin Workflow** shall support controlled creation, review, demonstration, or learning use of conceptual twins, data-linked twins, scenario twins, infrastructure twins, WFEH-B twins, disaster-risk twins, sensor-linked twins, public authority learning twins, readiness-room twins, or handoff-context twins. Digital Twin Workflows shall record model basis, data basis, assumptions, limitations, uncertainty, sensitivity, update status, public-safe interpretation, access controls, and correction path.

A Digital Twin Workflow shall not create operational control, forecast certainty, deployment authorization, public authority approval, procurement status, financeability, insurability, or execution authority.

### 14.3.3 Simulation workflow.

A **Simulation Workflow** shall support controlled scenario modeling, stress testing, sensitivity analysis, public authority learning, DRI learning, WFEH-B analysis, risk-layering discussion, AI evaluation, cyber exercise, disaster-risk learning, or handoff-context preparation. Simulation Workflows shall record assumptions, model limitations, input data status, output limitations, uncertainty, confidence where applicable, review status, and public-safe release rules.

Simulation output shall not be treated as prediction, warning, certification, public authority decision, finance decision, insurance decision, procurement decision, deployment approval, or operational command.

### 14.3.4 AI workflow.

An **AI Workflow** shall support controlled use, evaluation, review, summarization, classification, retrieval, model comparison, benchmark testing, agentic workflow review, prompt testing, tool-permission testing, output review, public-safe transformation, or AI-assisted analysis within recorded AI-use labels. AI Workflows shall include human review, tool permissions, logging, data leakage controls, prompt-injection controls, output classification, escalation triggers, kill-switch conditions where applicable, and AI incident pathways.

An AI Workflow shall not make high-stakes decisions, public authority decisions, employment decisions, procurement decisions, finance decisions, insurance decisions, community consent decisions, Indigenous consent decisions, or deployment decisions by default.

### 14.3.5 Data workflow.

A **Data Workflow** shall support data intake, classification, metadata creation, lineage capture, rights review, sensitivity review, quality assessment, transformation, aggregation, synthetic data generation, public-safe transformation, data paper preparation, data availability statement preparation, DICE routing, Registry recording, Marketplace listing, Reports inclusion, or handoff data context. Data Workflows shall apply data-use labels, AI-use labels, access class, retention rules, output review, and correction pathways.

A Data Workflow shall not create data rights, unrestricted reuse, AI training permission, data transfer authorization, protected knowledge permission, public authority status, handoff permission, or deployment authority.

### 14.3.6 Public authority learning workflow.

A **Public Authority Learning Workflow** shall present structured materials for learning by public authorities without converting those materials into official action. It may include technical briefings, dashboard demonstrations, DRI interpretation, Studio exercises, public-safe Reports, regulatory-literacy materials, procurement-boundary literacy, public finance literacy, emergency management literacy, or technology-readiness context.

Public Authority Learning Workflows shall include non-decision notices, no-warning notices, no-approval notices, no-procurement notices, no-public-finance notices, and no-execution notices. Any official public authority action shall remain external to the workflow.

### 14.3.7 Readiness workflow.

A **Readiness Workflow** shall support structured review of evidence sufficiency, method sufficiency, data sufficiency, AI-use sufficiency, cyber sufficiency, public-safe sufficiency, safeguard sufficiency, support sufficiency, reproducibility sufficiency, Grid inputs, TRL notes, assumptions, dependencies, diligence gaps, and handoff readiness questions. Readiness Workflows shall route gaps into Dockets, Foundry builds, Reports, Registry updates, Marketplace updates, or correction records.

Readiness Workflows shall not create certification, finance approval, insurance approval, public authority approval, procurement readiness, deployment authorization, or execution authority.

### 14.3.8 Handoff demonstration workflow.

A **Handoff Demonstration Workflow** shall demonstrate how an object, package, evidence record, data context, method context, Studio context, Grid input, TRL note, public-safe status, safeguard status, public authority dependency, legal dependency, finance or insurance question, procurement boundary, provider-neutrality note, sponsor-boundary note, recipient responsibility, correction pathway, or recall pathway may be organized for lawful downstream actors. It shall support understanding of dependencies and responsibilities.

A Handoff Demonstration Workflow shall not itself transfer authority, approve implementation, select providers, authorize procurement, authorize financing, authorize underwriting, approve deployment, grant consent, or execute a project.

### 14.3.9 Secure review workflow.

A **Secure Review Workflow** shall support controlled review of sensitive objects under heightened access, logging, output, confidentiality, and incident controls. It may apply to cyber-sensitive materials, infrastructure-sensitive materials, protected knowledge, controlled data, restricted models, secure code, legal-sensitive materials, public authority-sensitive records, or handoff-recipient-only materials.

Secure Review Workflows shall record reviewers, scope, limitations, outputs, restrictions, incidents, corrections, and archive status. Review does not create certification or approval by default.

### 14.3.10 Public-safe output workflow.

A **Public-Safe Output Workflow** shall transform restricted, technical, sensitive, or complex objects into public-safe summaries, reports, metadata, dashboards, guides, learning objects, Campaign materials, Marketplace listings, Registry descriptions, or Nexus Universe materials. It shall remove or mask unsafe details, protect sensitive information, preserve material caveats, include boundary notices, and record transformation decisions.

Public-safe output shall not convert restricted objects into open objects, nor shall it create approval, certification, warning authority, unrestricted reuse, or execution authority.

## 14.4 Runtime Controls

### 14.4.1 Identity and access management.

Controlled runtime environments shall apply identity and access management appropriate to room class, object class, sensitivity, jurisdictional context, participant role, and workflow purpose. Identity controls may include account verification, role assignment, organization affiliation where required, authentication, multi-factor authentication where appropriate, time-limited access, purpose-based access, revocation, and periodic access review.

Access shall be granted only for recorded purposes and may be suspended, revoked, narrowed, or audited where risk, misuse, overclaim, data concern, AI concern, cyber concern, privacy concern, protected knowledge concern, or boundary concern arises.

### 14.4.2 Least privilege.

Controlled runtime environments shall apply least privilege. Participants shall receive only the minimum access, functions, tools, datasets, models, outputs, exports, and collaboration permissions needed for the recorded workflow. Higher-risk actions, including export, download, model execution, query execution, code execution, tool invocation, AI use, data combination, or handoff packaging, shall require additional permission where appropriate.

Least privilege shall preserve data protection, public-safe release, protected knowledge controls, cyber resilience, public authority boundaries, finance boundaries, procurement neutrality, consent boundaries, and non-execution discipline.

### 14.4.3 No-download rules.

No-download rules shall apply where data, models, reports, code, protected knowledge, geospatial information, cyber-sensitive materials, infrastructure-sensitive materials, public authority-sensitive materials, handoff packages, or other objects should be viewed, queried, analyzed, or reviewed without extraction. No-download controls may restrict file download, copy-paste, screenshots, printing, local saving, bulk export, API extraction, model weight extraction, raw-data export, or derivative extraction.

No-download access does not create reuse rights. Where output is permitted, output shall be reviewed and recorded before release.

### 14.4.4 No-write-back rules.

No-write-back rules shall prevent controlled runtime users, AI agents, scripts, simulations, dashboards, or tools from writing to operational systems, source systems, public authority systems, production infrastructure, external repositories, underlying datasets, third-party systems, or live environments unless separately authorized. No-write-back controls are especially important for Studio demonstrations, digital twins, AI workflows, data rooms, public authority learning rooms, and handoff demonstrations.

No-write-back rules preserve the distinction between learning, review, simulation, and execution.

### 14.4.5 No-command rules.

No-command rules shall prevent controlled runtime environments from issuing operational commands, emergency instructions, infrastructure controls, system controls, public authority directives, procurement instructions, financial instructions, underwriting instructions, deployment commands, drone or robotics commands, OT/IoT commands, network commands, or field instructions by default. Demonstrations may simulate command logic but shall not command real systems unless a separate lawful execution environment is established outside DDPGF default posture.

No-command rules shall be explicit in Studio workflows, digital twin workflows, dashboards, AI workflows, and public authority learning workflows.

### 14.4.6 Output review.

Output review shall apply before controlled-room outputs are exported, published, cited, listed, displayed, routed, included in Reports, included in Marketplace, recorded in Registry, used in Academy, used in Campaigns, presented at Nexus Universe, used in Grid or TRL notes, or included in handoff context. Output review may include public-safe review, data review, AI-use review, cyber review, privacy review, legal-boundary review, safeguard review, protected knowledge review, geospatial review, accessibility review, finance-boundary review, procurement-boundary review, and public authority boundary review.

No controlled output shall be treated as approved for public release or downstream use until review is recorded.

### 14.4.7 Logging.

Controlled runtime environments shall maintain logs appropriate to room class and risk, including user access, file access, query execution, model execution, AI tool use, data export attempts, output generation, permission changes, download attempts, error events, incident events, review events, and archive events. Logs shall support auditability, incident response, correction, accountability, and trust.

Logging shall be privacy-aware and purpose-limited. Logs shall not be used for unauthorized worker surveillance, learner ranking, social scoring, public authority profiling, or commercial exploitation.

### 14.4.8 Audit trails.

Audit trails shall preserve meaningful histories of access, actions, changes, reviews, approvals within scope, corrections, withdrawals, recalls, exports, publications, Registry updates, Marketplace updates, Studio closures, Grid updates, TRL updates, and handoff package changes. Audit trails shall be retained according to retention, legal hold, security, privacy, and archive rules.

Audit trails shall support correctionability and institutional memory without converting review actions into certification or authority.

### 14.4.9 Data export controls.

Data export controls shall prevent unauthorized export of raw data, restricted data, protected knowledge, sensitive geospatial information, model outputs, AI outputs, cyber-sensitive information, public authority-sensitive materials, infrastructure-sensitive materials, or handoff-recipient-only records. Export may require purpose review, rights review, public-safe review, de-identification review, aggregation, masking, output review, steward approval, and logging.

Export permission shall be object-specific and shall not create future export rights, reuse rights, transfer rights, or publication rights beyond recorded scope.

### 14.4.10 AI-use controls.

AI-use controls shall govern whether and how AI may be used in controlled runtime environments. Controls shall include AI-use labels, prohibited uses, approved tools, approved models, approved prompts where applicable, retrieval restrictions, training restrictions, fine-tuning restrictions, agentic restrictions, tool-permission controls, human review, prompt-injection controls, data leakage controls, logging, output classification, incident response, and withdrawal conditions.

AI-use controls shall prevent automated authority, high-stakes decisions by default, unauthorized data disclosure, protected knowledge exposure, public-safe failures, and misleading AI output reliance.

### 14.4.11 Shutdown triggers.

Controlled runtime environments shall include shutdown triggers for data incidents, AI incidents, cyber incidents, privacy incidents, protected knowledge incidents, public authority boundary incidents, finance boundary incidents, procurement boundary incidents, consent overclaim incidents, deployment overclaim incidents, execution overclaim incidents, suspicious access, unauthorized export, unsafe output, vulnerability exposure, legal hold, or serious safeguard concerns. Shutdown may be full, partial, room-specific, workflow-specific, user-specific, object-specific, or export-specific.

Shutdown shall be recorded, reviewed, corrected, and either reinstated, narrowed, archived, or escalated according to incident severity.

### 14.4.12 Archive rules.

Controlled runtime environments shall have archive rules for workflows, rooms, logs, outputs, review records, permission records, incident records, correction records, reports, dashboards, model outputs, data outputs, public-safe summaries, handoff packages, and non-continuing work. Archive rules shall define retention, sealing, deletion, access class, sensitivity class, successor links, withdrawal status, recall status, and historical-use limits.

Archived runtime records shall preserve memory without authorizing current use, current access, current approval, current support, deployment, or execution.

## 14.5 Compute-to-Data Governance

### 14.5.1 Workload approval.

Compute-to-Data workloads shall be approved before execution. Approval shall consider purpose, data class, sensitivity, rights basis, AI-use label, user role, query type, model type, code provenance, security posture, output risk, re-identification risk, protected knowledge risk, public-safe risk, and jurisdictional constraints. Approved workloads may include aggregation, statistical analysis, feature extraction, quality checks, model evaluation, public-safe transformation, benchmarking, reproducibility checks, or controlled research.

Workload approval shall not imply that outputs are approved for publication, handoff, deployment, finance use, procurement use, or public authority use. Outputs require separate review.

### 14.5.2 User approval.

Compute-to-Data users shall be approved according to role, purpose, affiliation where required, training completion, confidentiality requirements, data-use permissions, AI-use permissions, conflict status, room class, jurisdictional constraints, safeguard obligations, and need-to-know. User approval may be time-limited, object-limited, workload-limited, room-limited, export-limited, or revocable.

User approval shall not create ownership, data rights, reuse rights, download rights, publication rights, or handoff authority.

### 14.5.3 Query controls.

Compute-to-Data query controls shall restrict what operations may be run against controlled data. Controls may include approved query templates, query review, query rate limits, aggregation thresholds, differential privacy where appropriate, suppression rules, output size limits, join restrictions, feature restrictions, model restrictions, code restrictions, and prohibited query patterns designed to prevent re-identification, leakage, inference attacks, protected knowledge exposure, or unsafe outputs.

Queries may be logged, reviewed, blocked, modified, or escalated where risk is detected.

### 14.5.4 Output review.

Compute-to-Data outputs shall be reviewed before export, sharing, publication, Marketplace listing, Registry update, Report inclusion, Studio display, Academy use, Campaign use, Grid input, TRL note, Nexus Universe presentation, or handoff packaging. Output review shall evaluate re-identification risk, data leakage, sensitive attribute disclosure, protected knowledge exposure, geospatial sensitivity, cyber sensitivity, public authority sensitivity, public-safe status, AI-use status, statistical validity, uncertainty, and boundary notices.

Output review shall determine whether outputs may be released openly, released as public-safe summaries, restricted, aggregated further, masked, rejected, corrected, or archived.

### 14.5.5 Privacy-preserving analytics.

Compute-to-Data may use privacy-preserving analytics, including aggregation, suppression, masking, de-identification, pseudonymization, synthetic data, differential privacy where appropriate, secure multiparty computation where appropriate, federated analytics where appropriate, confidential computing where appropriate, and clean-room methods where appropriate. Such methods shall be selected according to risk, data class, purpose, and feasibility.

Privacy-preserving analytics shall reduce risk but shall not automatically make data open, unrestricted, anonymous for all purposes, AI-training-permitted, public-safe, or handoff-ready.

### 14.5.6 Confidential computing where appropriate.

Confidential computing may be used where workloads require enhanced protection of data in use, including sensitive public authority data, health-sensitive data, protected knowledge, infrastructure-sensitive data, cyber-sensitive data, National Portfolio data, Observatory data, or handoff data context. Confidential computing records shall document purpose, enclave or protection model, workload scope, user scope, key management, logging, output review, limitations, and incident pathway.

Use of confidential computing shall not create a security guarantee, certification, unrestricted data right, or deployment authorization.

### 14.5.7 Secure enclave use.

Secure enclaves may be used to isolate compute, data, models, tools, and outputs for controlled workflows. Secure enclave use shall include approved environment configuration, access controls, workload approval, dependency review, logging, output review, incident response, teardown rules, and archive rules. Enclaves may be temporary, project-specific, national, secure-room-linked, public authority learning-linked, or handoff-recipient-linked.

Secure enclave use shall not imply public authority approval, provider validation, production readiness, financeability, insurability, or execution authority.

### 14.5.8 No raw data extraction.

Compute-to-Data shall default to no raw data extraction for restricted, protected, sovereign-sensitive, public authority-sensitive, community-sensitive, Indigenous protocol-sensitive where applicable, health-sensitive, youth-sensitive, cyber-sensitive, infrastructure-sensitive, geospatial-sensitive, Observatory, DRI, National Portfolio, and handoff-recipient-only data. Raw data extraction may occur only where separately authorized, legally permitted, rights-cleared, safeguarded, logged, and reviewed.

No raw data extraction shall be understood as a core public-good trust control, not merely a technical preference.

### 14.5.9 Audit records.

Compute-to-Data workflows shall maintain audit records of workload approvals, user approvals, queries, execution events, code versions, model versions, data versions, output reviews, export decisions, incidents, corrections, shutdowns, and archives. Audit records shall support accountability, reproducibility where safe, correction, legal compliance, safeguard compliance, and institutional memory.

Audit records shall be protected according to privacy, security, confidentiality, and retention requirements.

### 14.5.10 Incident response.

Compute-to-Data incident response shall address unauthorized access, unauthorized query, attempted extraction, data leakage, re-identification risk, protected knowledge exposure, AI misuse, prompt injection, model inversion, membership inference, cyber incident, privacy incident, public-safe failure, boundary overclaim, output misuse, or export violation. Response may include shutdown, access suspension, output recall, Registry update, Marketplace delisting, Report correction, handoff recall, public-safe notice, legal escalation, and archive action.

Incident response shall be proportionate, recorded, correctionable, and aligned with DDPGF stop-the-line discipline.

## 14.6 Studio and Room Boundary Rules

### 14.6.1 Secure room is not public authority approval.

Access to, participation in, or output from a Secure Room shall not constitute public authority approval, regulatory approval, compliance determination, permit, license, public warning, public finance allocation, procurement decision, emergency command, or governmental endorsement. Public authorities may learn in Secure Rooms, but official action requires a separate competent public authority process.

### 14.6.2 Data room access is not handoff permission.

Data Room access shall not create permission to hand off, export, reuse, publish, train AI systems on, transfer, disclose, commercialize, operationalize, or deploy data or data-derived outputs. Handoff permission requires separate handoff review, rights review, recipient responsibility, dependency records, public-safe controls, safeguard controls, and lawful authority.

### 14.6.3 Readiness room is not finance approval.

A Readiness Room may identify finance-readiness questions, insurance-readiness questions, assumptions, dependencies, diligence gaps, support status, evidence sufficiency, and handoff context, but it shall not create finance approval, bankability, investment advice, underwriting, donor commitment, public finance allocation, guarantee, transaction readiness, securities interest, or financeability.

### 14.6.4 Capital-reader room is not investment activity.

A Capital-Reader Room shall be no-reliance, non-soliciting, non-transactional, competition-compliant, confidentiality-aware, and regulated-perimeter controlled. It shall not constitute investment activity, securities offering, investment advice, investor roadshow, capital raise, fund marketing, loan application, financing commitment, guarantee, public finance allocation, or transaction negotiation by default.

### 14.6.5 Insurance-reader room is not underwriting.

An Insurance-Reader Room shall not constitute underwriting, insurance pricing, coverage approval, binding authority, risk transfer commitment, claim decision, insurance score, actuarial certification, insurability determination, or regulated insurance advice by default. Insurance-reader participation means controlled learning or readiness reading only within recorded scope.

### 14.6.6 Studio workflow is not deployment authorization.

A Studio workflow may demonstrate, simulate, review, transform, explain, analyze, or prepare digital-public-good objects, but it shall not authorize deployment, operational command, production use, public authority action, procurement, finance, insurance, provider selection, community implementation, Indigenous consent, or enterprise execution. Any deployment or implementation shall require separate lawful authority, competent actors, recipient responsibility, and recorded handoff outside default Studio status.


---

# 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/xiv.-studio.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.