# II. OBJECTS

## 2.1 Digital Object Taxonomy

### 2.1.1 Software objects.

Software objects shall include every code-based, executable, reusable, configurable, deployable, reference, analytical, instructional, integration, automation, or workflow-supporting artefact produced, adopted, adapted, localized, reviewed, listed, published, routed, archived, or handed off under DDPGF. Software objects may include repositories, libraries, packages, services, applications, dashboards, command-line tools, scripts, notebooks with executable code, APIs, SDKs, connectors, adapters, infrastructure-as-code templates, test suites, configuration files, deployment templates, reference implementations, sample applications, simulation engines, model-serving components, data-processing pipelines, visualization tools, security utilities, and public-good software baselines.

Software objects shall be governed as digital public-good objects only where they are assigned recorded identity, steward, version, license class, support class, repository status, security review status, dependency record, public-safe documentation status, correction pathway, and archive rule. A software object may be open-source, controlled-source, internal, sandbox, secure-room-only, Studio-only, reference-only, unsupported, community-supported, maintainer-supported, handoff-recipient-supported, deprecated, withdrawn, or archived according to its recorded state. Software availability shall not constitute warranty, production approval, security certification, procurement recommendation, provider validation, or deployment authorization.

### 2.1.2 Data objects.

Data objects shall include structured, semi-structured, unstructured, raw, processed, aggregated, synthetic, derived, metadata-only, public-safe, restricted, controlled, national, regional, global, observational, experimental, survey, geospatial, sensor, model-input, model-output, benchmark, dashboard, DRI, GRIx, DICE, Observatory, National Portfolio, Studio, Reports, Campaigns, Academy, Foundry, or handoff-relevant datasets and data packages. Data objects may include raw datasets, processed datasets, metadata records, data dictionaries, codebooks, schemas, feature sets, data pipelines, data extracts, aggregates, anonymized or de-identified releases, synthetic datasets, public-safe summaries, restricted tables, geospatial layers, sensor streams, Earth observation products, digital twin inputs, risk indicators, and data availability records.

Data objects shall be governed through source review, rights review, sensitivity classification, lineage capture, data-use labeling, AI-use labeling, access control, public-safe transformation, retention, deletion, sealing, correction, and archive. Data publication, data-room access, metadata exposure, or Marketplace discovery shall not create unrestricted data rights, cross-border transfer permission, AI-training permission, re-identification permission, public authority record status, handoff permission, or execution authority by implication.

### 2.1.3 Metadata objects.

Metadata objects shall include descriptive, structural, administrative, technical, provenance, rights, access, licensing, review, support, sensitivity, correction, archive, interoperability, and public-safe information attached to or associated with DDPGF objects. Metadata objects shall make digital public goods findable, understandable, reviewable, reusable, interoperable, correctable, citable, localizable, and archivable without requiring uncontrolled release of underlying controlled sources.

Metadata objects may be public even where the underlying object is restricted, secure-room-only, data-room-only, national-repository-only, handoff-recipient-only, or archive-only. Metadata shall not by itself create open data status, data access rights, license rights, consent, public authority status, approval, certification, procurement status, or deployment authorization. Metadata shall remain subject to sensitivity review where it could reveal protected knowledge, sensitive infrastructure, cyber-sensitive details, personal data, community-sensitive information, Indigenous protocol-sensitive information, confidential sources, or restricted operational details.

### 2.1.4 Model objects.

Model objects shall include statistical models, machine-learning models, foundation-model interfaces, fine-tuned models, retrieval-augmented systems, classifiers, forecasting models, optimization models, risk models, simulation models, digital twin models, decision-support models, evaluation harnesses, benchmark models, model cards, system cards, benchmark cards, configuration files, weights where lawfully held or released, prompts where recordable, evaluation datasets where permitted, and model-output packages. A model object may be open, controlled, internal, secure-room-only, Studio-only, evaluation-only, handoff-recipient-only, withdrawn, archived, or non-continuing according to recorded status.

Model objects shall be governed according to intended use, prohibited use, data provenance, training or configuration constraints, evaluation record, limitation statement, bias and harm review, human review, security review, AI-use label, access class, support class, correction pathway, withdrawal condition, and archive rule. Model release, model evaluation, model card publication, benchmark result, or system card listing shall not constitute AI safety certification, general validation, legal compliance determination, public authority approval, procurement readiness, financeability, insurability, professional advice, deployment authorization, or automated decision authority.

### 2.1.5 AI-agent objects.

AI-agent objects shall include agentic workflows, AI tool-use configurations, autonomous or semi-autonomous task workflows, retrieval agents, analysis agents, coding agents, orchestration agents, multi-agent systems, review agents, simulation agents, monitoring agents, Studio agents, public-safe drafting agents, data-room agents, secure-room agents, and any digital object that can select tools, call systems, retrieve data, transform outputs, initiate workflow steps, or recommend actions through an AI-enabled process. AI-agent objects shall be treated as controlled runtime objects by default unless a lower-risk classification is expressly recorded.

AI-agent objects shall require agent identity, intended use, prohibited use, tool-permission record, access boundary, human-in-the-loop or human-on-the-loop requirement, no-command rules, no-write-back rules, no-unapproved-export rules, logging, output review, escalation triggers, kill-switch conditions, prompt-injection controls, data leakage controls, incident pathways, correction pathway, and archive rule. AI-agent output shall not be treated as determination, public authority decision, finance decision, insurance decision, procurement decision, consent determination, deployment authorization, operational command, or execution instruction.

### 2.1.6 Ontology objects.

Ontology objects shall include controlled vocabularies, taxonomies, classifications, semantic models, entity models, relationship models, knowledge graph structures, GRIx categories, DRI category structures, WFEH-B taxonomies, risk category structures, technology category structures, safeguard category structures, handoff dependency categories, public authority boundary categories, finance and insurance boundary categories, and interoperability mappings. Ontology objects shall preserve semantic consistency across Nexus while permitting lawful localization, translation, extension, and controlled adaptation.

Ontology objects shall be governed through term proposal, definition review, scope note, source mapping, versioning, localization, translation, conflict resolution, deprecation, correction, and archive. An ontology object shall not constitute legal classification, public authority determination, rating, certification, standards adoption, compliance finding, procurement status, finance status, insurance status, or consent determination by implication.

### 2.1.7 Schema objects.

Schema objects shall include data schemas, metadata schemas, API schemas, evidence schemas, report schemas, Registry schemas, Marketplace schemas, Studio workflow schemas, Grid schemas, TRL evidence schemas, credential schemas, proof receipt schemas, handoff package schemas, correction schemas, archive schemas, and any structured template used to make Nexus digital objects interoperable, machine-readable, reviewable, or reusable.

Schema objects shall be versioned, documented, reviewable, and governed for backward compatibility, localization, validation, deprecation, migration, and correction. Schema conformance shall not constitute certification, legal compliance, standards conformance, data quality approval, public authority approval, procurement approval, financeability, insurability, deployment authorization, or execution authority unless separately and lawfully recorded by a competent process outside default DDPGF status.

### 2.1.8 API objects.

API objects shall include public APIs, controlled APIs, internal APIs, data APIs, model APIs, Registry APIs, Marketplace APIs, Studio APIs, Campaign APIs, Reports APIs, DRI APIs, Observatory APIs, Academy APIs, Foundry APIs, Grid APIs, handoff package APIs, authentication profiles, authorization profiles, API contracts, endpoint definitions, SDK bindings, connector definitions, adapter definitions, rate-limit rules, logging rules, deprecation notices, and API documentation.

API objects shall be governed through access class, authentication, authorization, rate limits, abuse prevention, data minimization, public-safe output filtering, logging, support class, versioning, deprecation, correction, and archive. API availability shall not create data rights, service warranty, uptime commitment, provider validation, certification, procurement status, public authority approval, handoff permission, deployment authorization, or execution authority by implication.

### 2.1.9 Dashboard objects.

Dashboard objects shall include visual interfaces, operating views, DRI dashboards, WFEH-B dashboards, Observatory dashboards, National Portfolio dashboards, Campaign dashboards, Foundry dashboards, Reports dashboards, Marketplace dashboards, Registry dashboards, Academy dashboards, Studio dashboards, Grid dashboards, handoff dependency dashboards, geospatial dashboards, indicator dashboards, and public-safe visual summaries.

Dashboard objects shall record source basis, update cadence, confidence labels, uncertainty labels, limitation notes, sensitivity masking, accessibility status, public-safe status, decision-support boundary, correction pathway, and archive rule. A dashboard shall not constitute public authority decision, public warning, emergency command, official map, country ranking, provider validation, finance signal, insurance score, procurement recommendation, forecast certainty, or deployment authorization.

### 2.1.10 Digital twin objects.

Digital twin objects shall include 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, handoff-context twins, simulation-linked twins, geospatial twins, operationally relevant but non-command twins, and digital twin documentation, assumptions, inputs, outputs, limitations, and model basis records.

Digital twin objects shall be governed through data basis, model basis, assumptions, uncertainty, confidence, sensitivity, scenario scope, access controls, no-command rules, no-write-back rules, output review, public-safe interpretation, correction, and archive. A digital twin object shall not create operational control, public authority decision, deployment approval, forecast certainty, emergency command, infrastructure command, financeability, insurability, procurement approval, or execution authority.

### 2.1.11 Simulation objects.

Simulation objects shall include scenario simulations, risk simulations, climate simulations, disaster simulations, WFEH-B simulations, cyber-physical simulations, infrastructure simulations, supply-chain simulations, digital twin simulations, AI evaluation simulations, red-team simulations, stress tests, tabletop simulation records, Studio simulation workflows, model limitation records, and simulation output packages.

Simulation objects shall record scenario assumptions, data basis, model basis, uncertainty, confidence, sensitivity, limitations, scope, review status, public-safe status, and correction pathway. Simulation output shall not constitute forecast certainty, public warning, certification, regulatory approval, public authority decision, finance approval, insurance underwriting, procurement decision, operational command, deployment authorization, or execution instruction.

### 2.1.12 Notebook objects.

Notebook objects shall include computational notebooks, reproducibility packages, teaching notebooks, analysis notebooks, data-processing notebooks, model-evaluation notebooks, visualization notebooks, simulation notebooks, public-safe demonstration notebooks, controlled-room notebooks, secure-room notebooks, and handoff-context notebooks. Notebook objects may combine code, data references, narrative explanation, outputs, charts, model calls, and reproducibility instructions.

Notebook objects shall be governed as executable and knowledge objects. They shall include dependency records, environment records, data-use labels, AI-use labels where applicable, output classification, security review where required, public-safe review where required, license or use conditions, support class, correction pathway, and archive rule. Notebook execution shall not create data rights, model approval, public authority decision, deployment authorization, warranty, or execution authority.

### 2.1.13 Report objects.

Report objects shall include Nexus Reports, technical reports, public-safe summaries, National Portfolio reports, WFEH-B reports, DRR reports, DRF reports, DRI reports, DICE reports, GRIx reports, Observatory reports, Foundry reports, Campaign reports, Academy reports, Labs reports, Risk Agency reports, Nexus Universe reports, Grid and TRL reports, handoff context notes, correction reports, archive reports, repository deposit packages, DOI-linked publications, and controlled knowledge products.

Report objects shall include metadata, author or steward record, source basis, evidence class, review status, public-safe status, data availability statement, AI-use statement where applicable, license or use conditions, correction pathway, and archive rule. Report publication shall not create approval, public warning, certification, financeability, procurement status, public authority decision, country ranking, or execution authority.

### 2.1.14 Learning objects.

Learning objects shall include courses, modules, units, lessons, labs, scenarios, simulations, Studio exercises, field exercises, review exercises, public-safe reporting exercises, contribution tasks, quests, bounties, builds, capstones, portfolio artefacts, instructor packs, learner guides, micro-learning assets, open educational resources, risk literacy materials, public authority learning materials, and handoff literacy materials.

Learning objects shall be governed through learning objective, competency mapping, audience, prerequisites, review status, accessibility status, language status, public-safe status, data-use and AI-use constraints, credential linkage where applicable, support class, correction pathway, and archive rule. Learning object completion shall not create professional license, employment status, procurement eligibility, public authority competence, deployment authorization, or execution authority.

### 2.1.15 Credential objects.

Credential objects shall include micro-credentials, digital badges, evidence-of-learning records, ILA-linked records, iCRS-linked recognition records, WILP records, skills wallet entries, assessment records, verification metadata, revocation records, suspension records, renewal records, badge display objects, and credential Registry records. Credential objects shall be bounded evidence records, not professional licensing instruments by default.

Credential objects shall record issuer, scope, evidence basis, assessment method, review level, expiry, renewal, display status, privacy settings, verification pathway, correction pathway, withdrawal pathway, and archive rule. A credential object shall not constitute degree, professional license, employment guarantee, wage guarantee, visa or immigration status, procurement qualification, public authority approval, deployment authorization, or community consent unless separately and lawfully established.

### 2.1.16 Campaign objects.

Campaign objects shall include campaign pages, pledge records, signature records, volunteer records, support records, donation records where lawful, campaign dashboards, campaign public-safe stories, campaign team records, chapter records, ambassador records, quest and bounty campaign tasks, campaign reports, Support Ledgers, campaign correction notices, campaign archives, and Nexus Universe routing records.

Campaign objects shall be governed through campaign purpose, scope, public-safe review, trust and safety controls, fraud controls, sponsor controls, provider controls, public authority boundary controls, community consent boundary controls, support records, correction pathway, and archive rule. Campaign participation, signature, pledge, donation, volunteer involvement, media attention, or campaign success shall not constitute vote, mandate, binding finance, employment, public authority approval, donor commitment, community consent, procurement status, or execution authority.

### 2.1.17 Registry objects.

Registry objects shall include object records, status records, version records, review records, data-use records, AI-use records, license records, support records, provider contribution records, sponsor support records, public authority participation records, correction records, withdrawal records, recall records, archive records, and status-truth entries for DDPGF objects. Registry objects shall preserve lifecycle memory and boundary discipline across Nexus.

Registry objects shall not be treated as universal validation. Registry status shall distinguish draft, active, under review, public-safe, controlled, supported, unsupported, deprecated, suspended, withdrawn, recalled, superseded, archived, and non-continuing states. Registry recordation shall not create certification, approval, legal equivalence, procurement status, financeability, insurability, public authority decision, consent, deployment authorization, or execution authority.

### 2.1.18 Marketplace objects.

Marketplace objects shall include listings, metadata displays, discovery cards, support-discovery entries, learning-discovery entries, contribution opportunities, software listings, data listings, model listings, API listings, dashboard listings, Studio workflow listings, learning listings, report listings, campaign listings, Foundry object listings, National Portfolio listings, and handoff context listings. Marketplace objects shall support discovery, reuse, learning, contribution, support, and demand-signal visibility.

Marketplace objects shall include listing metadata, steward, version, access class, license class, support class, Registry status, review status, public-safe status, correction pathway, and boundary notices. Marketplace listing, featuring, discovery, download, reuse interest, support interest, or handoff relevance shall not constitute endorsement, procurement approval, provider validation, public authority approval, finance commitment, insurance approval, certification, or implementation authorization.

### 2.1.19 Studio workflow objects.

Studio workflow objects shall include controlled runtime workflows, dashboard workflows, digital twin workflows, scenario workflows, AI workflow reviews, data-room workflows, secure-room workflows, public authority learning workflows, readiness-room workflows, capital-reader room workflows, insurance-reader room workflows, donor-reader room workflows, Nexus Universe workflows, handoff demonstration workflows, and controlled output review packages.

Studio workflow objects shall include access controls, role permissions, no-write-back rules, no-command rules, output review, logging, AI-use restrictions, data export restrictions, public-safe restrictions, shutdown triggers, correction triggers, and archive rules. Studio workflows shall not constitute deployment, public authority decision, finance approval, underwriting decision, procurement approval, operational command, data right, handoff permission, or execution authority.

### 2.1.20 Grid and TRL objects.

Grid and TRL objects shall include Grid inputs, readiness records, TRL 1–10 evidence notes, maturity-input records, evidence sufficiency records, method sufficiency records, data sufficiency records, AI-use sufficiency records, cyber sufficiency records, public-safe sufficiency records, safeguard sufficiency records, support sufficiency records, reproducibility sufficiency records, correction sufficiency records, review gate records, downgrade records, suspension records, withdrawal records, reinstatement records, and archive records.

Grid and TRL objects shall classify bounded evidence within recorded scope. They shall not create certification, maturity certification, procurement readiness, financeability, insurability, public authority approval, deployment authorization, product approval, safety approval, or execution authority.

### 2.1.21 Proof receipt objects.

Proof receipt objects shall include records evidencing that a defined action, contribution, review, submission, publication, update, correction, access event, routing event, handoff step, support event, or lifecycle transition occurred within a bounded DDPGF context. Proof receipts may be linked to Dockets, ILA records, iCRS records, Registry records, Marketplace listings, Studio workflows, Reports, Campaigns, Foundry builds, Grid inputs, TRL notes, National Portfolio records, Nexus Universe outputs, and handoff packages.

Proof receipt objects shall prove occurrence within scope, not substantive approval beyond scope. A proof receipt shall not constitute certification, legal compliance, public authority approval, credential status, financeability, procurement status, consent, deployment authorization, or execution authority unless such status is separately and lawfully created and expressly recorded.

### 2.1.22 National Portfolio objects.

National Portfolio objects shall include national context records, national systems-risk maps, national challenge briefs, evidence need records, Observatory need records, Core Build requests, safeguard records, public authority learning records, readiness question records, Competence Cell workplans, Universe arena routing records, national data objects, national software objects, national dashboard objects, national DRI objects, national Academy objects, national Reports objects, national Studio objects, national Marketplace objects, national handoff objects, and national portfolio archives.

National Portfolio objects shall preserve national ownership, localization, public authority boundary discipline, data sovereignty, community safeguards, Indigenous protocols where applicable, protected knowledge controls, and lawful handoff pathways. A National Portfolio object shall not constitute country ranking, public authority adoption, procurement status, financeability, implementation authorization, community consent, Indigenous consent, or execution authority by implication.

### 2.1.23 Nexus Universe objects.

Nexus Universe objects shall include arena records, participation records, Core Build records, public authority learning records, readiness question records, support records, Marketplace listings, Registry updates, Reports, Campaign updates, Foundry continuation records, National Portfolio updates, handoff dependency notes, Studio demonstration records, room records, correction records, and archive records created or routed through a Nexus Universe cycle.

Nexus Universe objects shall preserve the annual surge as record-bearing public-good formation, not event publicity alone. Attendance, visibility, demonstration, sponsor presence, provider participation, public authority presence, capital-reader presence, insurance-reader presence, media attention, or public display shall not constitute endorsement, approval, public authority decision, finance, underwriting, procurement, validation, consent, deployment, or execution.

### 2.1.24 Lawful handoff objects.

Lawful handoff objects shall include handoff context notes, evidence packages, data context packages, method context packages, Studio context packages, Grid and TRL context packages, public-safe status notes, safeguard status notes, public authority dependency notes, legal dependency notes, finance and insurance question notes, procurement boundary notes, provider-neutrality notes, sponsor-boundary notes, recipient responsibility notes, correction pathways, recall pathways, handoff dependency registers, and handoff archives.

Lawful handoff objects shall transfer context and dependencies, not authority. They shall not create approval, mandate, consent, procurement status, financeability, insurability, underwriting approval, public authority action, implementation authorization, operational command, legal responsibility, or execution authority by implication. Downstream actors shall remain responsible for independent diligence, legal authority, finance, insurance, procurement, community engagement, deployment, operation, and execution through separate lawful processes.

## 2.2 Object Identity

### 2.2.1 Unique object identifier.

Each DDPGF object shall be assigned or linked to a unique object identifier sufficient to distinguish it from all other objects, versions, forks, translations, localizations, derivatives, public-safe summaries, controlled sources, handoff packages, and archive records. The identifier shall support traceability across Nexus Registry, Nexus Marketplace, Nexus Reports, Nexus Studio, Nexus Grid, TRL records, DICE, GRIx, DRI, Nexus Observatory, Nexus Rails, Nexus Network, Nexus Academy, Nexus Foundry, Nexus Universe, National Portfolios, and lawful handoff records.

The unique object identifier may be internal, public, repository-based, DOI-linked, Registry-linked, namespace-based, jurisdiction-linked, version-linked, or otherwise structured according to DDPGF rules. The identifier shall not itself create certification, approval, legal status, procurement status, finance status, data rights, or execution authority.

### 2.2.2 Object name.

Each DDPGF object shall have an object name that is clear, stable within version, non-misleading, and consistent with its object family, object class, scope, and boundary notices. Object names shall not imply certification, approval, official public authority status, procurement readiness, financeability, insurability, community consent, Indigenous consent, deployment authorization, operational control, or Nexus-wide endorsement unless such status is separately and lawfully recorded.

Where an object is experimental, draft, controlled, public-safe, restricted, unsupported, deprecated, withdrawn, recalled, archived, or non-continuing, the object name or associated display metadata shall be sufficiently clear to prevent reliance on outdated or misleading status.

### 2.2.3 Object family.

Each DDPGF object shall be assigned to an object family that identifies its broad governance type, including software, data, metadata, model, AI-agent, ontology, schema, API, dashboard, digital twin, simulation, notebook, report, learning, credential, campaign, Registry, Marketplace, Studio workflow, Grid and TRL, proof receipt, National Portfolio, Nexus Universe, lawful handoff, infrastructure, repository, or other approved family.

Object family classification shall determine baseline metadata, review gates, access rules, support expectations, public-safe controls, correction requirements, archive rules, and boundary notices. An object may belong to multiple families where it performs multiple functions, provided that the most restrictive applicable controls are recorded.

### 2.2.4 Object class.

Each DDPGF object shall be assigned an object class within its object family. Object class shall provide operational specificity, such as repository, API, dataset, schema, model card, system card, benchmark card, dashboard, DRI indicator, Studio workflow, micro-credential, campaign support record, Registry status record, Marketplace listing, TRL evidence note, National Portfolio dashboard, or handoff dependency package.

Object class shall determine required metadata, review needs, sensitivity questions, support class options, license requirements, publication options, controlled-access needs, interoperability expectations, and boundary notices. Object class shall not be used to overstate authority or maturity. A “reference implementation,” “benchmark,” “readiness note,” “public-safe summary,” “proof receipt,” or “handoff package” shall mean only what its class permits.

### 2.2.5 Object version.

Each DDPGF object shall have a version record sufficient to distinguish its current form from prior drafts, releases, revisions, corrections, localizations, translations, forks, derivatives, public-safe summaries, archived versions, superseded versions, withdrawn versions, and recalled versions. Versioning may use semantic versioning, date-based versioning, repository commits, Registry states, publication versions, DOI versions, schema versions, model versions, data versions, or other approved methods.

Version records shall identify material changes, correction history, dependency changes, review status changes, support status changes, access-class changes, license changes, public-safe status changes, and archive status. Use of an outdated version shall remain subject to archive-not-current and successor-link rules where applicable.

### 2.2.6 Object steward.

Each DDPGF object shall identify an object steward responsible for lifecycle governance within the recorded scope. The steward may be a Nexus body, GCRI unit, The Global Risks Forum unit, The Global Risks Alliance unit, Nexus Foundry maintainer, DICE steward, Registry steward, Marketplace steward, Reports steward, Academy steward, National Node, National Working Group, Competence Cell, repository maintainer, data steward, model steward, ontology steward, public-safe reviewer, archive steward, or other recorded responsible role.

Stewardship shall not mean ownership by default, certification authority, execution authority, public authority status, procurement authority, finance authority, or warranty responsibility. Stewardship shall mean responsibility for maintaining the object record, routing review, preserving boundary notices, initiating correction where needed, and ensuring archive or non-continuation where appropriate.

### 2.2.7 Object source pathway.

Each DDPGF object shall record its source pathway, including whether it originated from Nexus Foundry, DICE, GRIx, DRI, Nexus Observatory, Nexus Labs, Nexus Reports, Nexus Academy, Risk Academy, Nexus Campaigns, Nexus Studio, Nexus Grid, Nexus Universe, Nexus Marketplace, Nexus Registry, National Portfolio, National Working Group, Competence Cell, public authority learning room, provider contribution, sponsor-supported activity, community contribution, Indigenous protocol-sensitive process where applicable, research collaboration, repository import, external open-source project, enterprise handoff pathway, or other approved source.

Source pathway records shall identify provenance and governance context, not endorsement or authority. Provider contribution shall not create provider validation. Sponsor-supported activity shall not create sponsor control. Public authority participation shall not create public authority approval. Community contribution shall not create consent. External source adoption shall not create warranty, certification, or legal equivalence.

### 2.2.8 Object jurisdictional context.

Each DDPGF object shall identify jurisdictional context where relevant, including global, regional, national, subnational, local, cross-border, sovereign-sensitive, public authority-sensitive, community-sensitive, Indigenous protocol-sensitive, data localization, export-control-sensitive, privacy-law-sensitive, health-data-sensitive, cyber-sensitive, infrastructure-sensitive, or handoff-recipient jurisdictional conditions.

Jurisdictional context shall guide localization, access, data transfer, repository location, license choice, publication, public-safe transformation, public authority boundary notices, and lawful handoff dependency records. Jurisdictional context shall not constitute legal advice, public authority determination, regulatory approval, compliance certification, or permission to operate.

### 2.2.9 Object access class.

Each DDPGF object shall have an access class. Access classes may include open public, controlled public, internal, restricted, secure-room-only, data-room-only, clean-room-only, protected-knowledge-room-only, public authority learning room, readiness-room-only, capital-reader-room-only, insurance-reader-room-only, donor-reader-room-only, national-repository-only, sovereign-repository-only, metadata-only, Studio-only, handoff-recipient-only, archive-only, suspended, withdrawn, recalled, or non-continuing.

Access class shall determine who may view, use, download, execute, cite, reuse, localize, fork, publish, or receive the object. Access class shall not create data rights, public authority approval, finance status, insurance status, procurement status, consent, deployment authorization, or execution authority.

### 2.2.10 Object lifecycle state.

Each DDPGF object shall have a lifecycle state indicating its status within the DDPGF lifecycle. Lifecycle state shall be one of, or map to, concept, intake, classified, draft, in build, in review, public-safe transformed, Registry-recorded, Marketplace-listed, published, supported, unsupported, deprecated, suspended, corrected, superseded, withdrawn, recalled, archived, or non-continuing.

Lifecycle state shall be reflected in Registry status where appropriate and shall be displayed in public or controlled contexts where necessary to prevent misuse. Lifecycle state shall not be confused with certification, approval, production readiness, or implementation authorization.

## 2.3 Object Metadata

### 2.3.1 Title.

Each DDPGF object shall have a title that accurately identifies the object in plain, technical, and public-safe terms as applicable. The title shall be sufficiently specific to distinguish the object from related versions, forks, translations, localizations, derivatives, summaries, controlled sources, and archive records. Titles shall avoid misleading authority language, certification language, procurement language, finance language, public authority language, warning language, consent language, and deployment language unless such status is separately and lawfully recorded.

### 2.3.2 Description.

Each DDPGF object shall include a description stating what the object is, what it is for, what it is not for, the context in which it was created, the user or steward audience, the object family and class, and any major limitations. The description shall be written so that reviewers, users, contributors, public authority learning participants, national actors, Marketplace users, Registry stewards, Studio users, and lawful handoff recipients can understand the object without relying on informal explanations.

The description shall not overstate maturity, support, completeness, certification, approval, public authority relevance, finance relevance, insurance relevance, procurement relevance, consent status, or deployment readiness.

### 2.3.3 Purpose.

Each DDPGF object shall state its purpose. Purpose shall identify the public-good need, Nexus function, risk-reduction function, learning function, evidence function, data function, software function, model function, observability function, publication function, campaign function, Studio function, Grid function, National Portfolio function, Nexus Universe function, or handoff context function that the object serves.

Purpose limitation shall apply. Objects shall not be reused for materially different purposes without review where the new use could affect data rights, AI use, public-safe status, sensitivity, security, privacy, community safeguards, Indigenous protocols, public authority boundaries, finance boundaries, procurement boundaries, or handoff responsibilities.

### 2.3.4 Scope.

Each DDPGF object shall include a scope statement defining what the object covers, what it excludes, the geographic, technical, temporal, jurisdictional, thematic, population, data, model, software, workflow, or handoff boundaries that apply, and the level of evidence or review supporting the object. Scope shall be used to prevent overextension, overclaim, and misuse.

An object shall not be treated as globally valid, nationally approved, production-ready, public authority-ready, finance-ready, insurance-ready, procurement-ready, or generally deployable unless such scope is separately and lawfully recorded through competent processes.

### 2.3.5 Source class.

Each DDPGF object shall identify its source class, including whether sources are primary, secondary, derived, contributed, observed, simulated, synthetic, public, controlled, restricted, proprietary, community-provided, Indigenous protocol-sensitive where applicable, public authority-sensitive, research-derived, model-generated, AI-assisted, sensor-derived, geospatial, cyber-sensitive, health-sensitive, infrastructure-sensitive, or handoff-provided.

Source class shall determine review obligations, public-safe treatment, data-use rules, AI-use rules, access rules, attribution, sensitivity labels, and correction pathways. Source class shall not validate source quality by default; it shall classify source type and governance needs.

### 2.3.6 Evidence class.

Each DDPGF object shall identify its evidence class, including whether the object is concept-level, draft, exploratory, reviewed, independently reviewed, reproducible, simulation-based, observed, benchmarked, field-informed, public-safe, controlled, handoff-contextual, or archive-only. Evidence class shall describe the level and nature of support for the object within its recorded scope.

Evidence class shall not constitute certification, approval, public authority determination, financeability, insurability, procurement readiness, or deployment readiness. It shall guide appropriate use and review.

### 2.3.7 Data-use label.

Each DDPGF object involving data shall include a data-use label. Data-use labels shall identify whether data may be viewed, downloaded, reused, transformed, cited, aggregated, combined, localized, published, used for AI retrieval, used for AI evaluation, used for AI training, used in secure rooms, used in compute-to-data workflows, used for handoff context, or used only as metadata. Data-use labels shall also identify prohibited uses where required.

Data-use labels shall bind object use within DDPGF governance and shall travel with derivatives, summaries, dashboards, reports, models, notebooks, and handoff packages where relevant. Data-use labels shall not create broader data rights than the underlying law, license, consent, permission, source agreement, community protocol, Indigenous protocol, or access decision permits.

### 2.3.8 AI-use label.

Each DDPGF object that may be used with AI shall include an AI-use label where relevant. AI-use labels may include no-AI use, retrieval-only, summarization with review, classification with review, evaluation-only, fine-tuning permitted, training permitted, agentic use prohibited, secure-room AI only, public-safe AI output only, or other approved labels.

AI-use labels shall govern how AI systems, models, agents, and workflows may interact with the object. Absence of a permissive AI-use label shall not imply permission for AI training, fine-tuning, agentic use, automated decision-making, data extraction, or uncontrolled output publication.

### 2.3.9 License class.

Each DDPGF object shall identify its license class or use-condition class. License classes may include open-source software license, open data license, Creative Commons license, documentation license, model license, dataset license, restricted-use license, non-commercial restriction where appropriate, no-AI-training restriction where appropriate, handoff-recipient-only restriction, internal-use restriction, public-safe-use restriction, contributor agreement condition, or no-public-license status.

License class shall be reviewed for compatibility with public-good use, reuse, attribution, modification, redistribution, localization, commercial support, handoff, and archive. License shall not create warranty, endorsement, unrestricted use, certification, or public authority approval.

### 2.3.10 Review status.

Each DDPGF object shall have a review status. Review status may include not reviewed, intake reviewed, metadata reviewed, technical reviewed, data reviewed, AI reviewed, cyber reviewed, privacy reviewed, public-safe reviewed, safeguard reviewed, legal-boundary reviewed, finance-boundary reviewed, procurement-boundary reviewed, handoff reviewed, independently reviewed, correction reviewed, suspended pending review, or archived after review.

Review status shall be displayed or recorded sufficiently to prevent overreliance. Review status shall not constitute certification, official approval, public authority decision, financeability, insurability, procurement approval, deployment approval, or execution authority.

### 2.3.11 Support class.

Each DDPGF object shall have a support class. Support classes may include unsupported public release, community-supported, maintainer-supported, Academy-supported, Foundry-supported, National Node-supported, Studio-supported, handoff-recipient-supported, time-limited support, sponsor-supported without control, provider-supported without validation, archived support, or no-support status.

Support class shall define expected maintenance, response, correction, documentation, issue handling, and support boundary. Support class shall not create warranty, service-level commitment, provider validation, procurement status, or operational guarantee unless separately contracted and recorded outside default DDPGF status.

### 2.3.12 Public-safe status.

Each DDPGF object shall identify public-safe status. Public-safe status may include not public-safe reviewed, internal only, controlled public, public-safe summary available, open public, sensitive content removed, geospatial masked, cyber-sensitive details removed, protected knowledge excluded, community-safe reviewed, Indigenous protocol-sensitive restrictions applied where applicable, public authority language reviewed, finance language reviewed, procurement language reviewed, or public release not permitted.

Public-safe status shall govern release, publication, Marketplace listing, Reports routing, dashboard display, campaign use, Academy use, Nexus Universe display, and handoff summaries. Public-safe status shall not make an object official, complete, certified, approved, or unrestricted.

### 2.3.13 Sensitivity class.

Each DDPGF object shall identify sensitivity class where applicable. Sensitivity classes may include open, public-safe, controlled, restricted, public authority-sensitive, community-sensitive, Indigenous protocol-sensitive where applicable, protected knowledge, youth-sensitive, health-sensitive, cyber-sensitive, infrastructure-sensitive, geospatial-sensitive, dual-use-sensitive, export-control-sensitive, sovereign-sensitive, finance-boundary-sensitive, procurement-boundary-sensitive, handoff-recipient-only, archive-only, or other approved class.

Sensitivity class shall determine access, review, masking, transformation, localization, repository routing, secure-room use, public-safe rules, AI-use rules, correction, and archive. The most restrictive applicable sensitivity class shall govern where ambiguity exists.

### 2.3.14 Correction pathway.

Each DDPGF object shall include a correction pathway identifying how errors, incidents, overclaims, vulnerabilities, outdated status, misuse, license issues, data issues, AI issues, public-safe issues, sensitivity issues, community safeguard issues, protected knowledge issues, or handoff issues may be reported, reviewed, corrected, suspended, withdrawn, recalled, superseded, publicly repaired, archived, or marked non-continuing.

Correction pathway shall include steward responsibility, notification rules where applicable, Registry update requirements, Marketplace delisting or update rules, Reports correction rules, repository patching rules, public-safe notice rules, handoff recall rules, and archive rules. Objects without correction pathway shall not be treated as ready for release or reuse except under explicitly recorded exceptional conditions.

### 2.3.15 Archive rule.

Each DDPGF object shall include an archive rule defining when and how the object will be archived, what metadata will remain visible, what access restrictions apply, what successor links must be included, what correction history must be preserved, what license or use conditions remain, what public-safe status applies, whether the object is historical-use-only, and whether the object may be restored, superseded, or permanently non-continuing.

Archive rule shall prevent stale objects from being mistaken for current authority. Archive shall preserve institutional memory without implying current validity, support, approval, deployment readiness, or execution authority.

## 2.4 Object Lifecycle States

### 2.4.1 Concept.

The concept state shall apply when a digital-public-good object has been proposed but not yet accepted for intake. A concept may describe a need, idea, candidate object, source possibility, software feature, dataset, model, report, dashboard, learning object, Studio workflow, Marketplace listing, Registry record, Grid input, TRL note, National Portfolio object, Nexus Universe output, or handoff package. Concept state shall not authorize build, publication, listing, release, reliance, deployment, or handoff.

### 2.4.2 Intake.

The intake state shall apply when an object candidate has entered DDPGF intake for initial purpose, scope, source, steward, sensitivity, access, review, and boundary classification. Intake shall determine whether the object proceeds, requires more information, is redirected, is rejected, is restricted, or is stopped. Intake state shall not constitute approval, review completion, public-safe status, support commitment, or readiness.

### 2.4.3 Classified.

The classified state shall apply when an object has received initial object family, object class, source class, evidence class, access class, sensitivity class, data-use label, AI-use label where applicable, review pathway, support expectation, correction pathway, and archive rule. Classification shall enable governance but shall not validate the object’s content, quality, legality, readiness, or use.

### 2.4.4 Draft.

The draft state shall apply when an object is under preparation but not yet ready for formal review, release, listing, publication, or handoff routing. Draft objects may be shared internally or within controlled spaces according to access class. Draft status shall be clearly marked to prevent reliance, citation as final, external claims, public authority use, finance use, procurement use, or implementation use.

### 2.4.5 In build.

The in-build state shall apply when the object is actively being created, coded, assembled, cleaned, modeled, documented, translated, localized, configured, tested, or packaged. In-build objects shall remain subject to repository controls, contribution controls, data controls, AI-use controls, security controls, public-safe controls, and safeguard controls. In-build status shall not imply readiness, support, validation, or release.

### 2.4.6 In review.

The in-review state shall apply when the object is undergoing required review. Review may include technical, evidence, data, AI, cyber, privacy, public-safe, safeguard, license, accessibility, interoperability, public authority boundary, finance boundary, procurement boundary, provider-neutrality, sponsor-boundary, handoff, or archive review. In-review status shall not be represented as approval or completion.

### 2.4.7 Public-safe transformed.

The public-safe transformed state shall apply when an object has been modified, summarized, redacted, aggregated, masked, translated, reframed, or otherwise transformed so that it may be released or displayed in a public-safe manner within recorded limits. Public-safe transformation may exclude sensitive data, protected knowledge, cyber-sensitive details, sensitive geospatial information, restricted source material, public authority overclaim language, finance overclaim language, procurement overclaim language, or consent overclaim language. Public-safe transformed status shall not imply unrestricted use or underlying source release.

### 2.4.8 Registry-recorded.

The Registry-recorded state shall apply when the object has an entry in Nexus Registry preserving object identity, status, version, review state, support state, access class, public-safe status, correction pathway, archive rule, and boundary notices. Registry-recorded status shall create status truth within Nexus but shall not create certification, approval, legal equivalence, procurement status, financeability, insurability, consent, deployment authorization, or execution authority.

### 2.4.9 Marketplace-listed.

The Marketplace-listed state shall apply when the object is discoverable through Nexus Marketplace according to listing governance. Marketplace listing may occur for open, controlled, metadata-only, learning, support, contribution, or handoff-awareness purposes. Marketplace-listed status shall not constitute endorsement, procurement approval, vendor validation, public authority approval, finance signal, insurance signal, certification, or implementation authorization.

### 2.4.10 Published.

The published state shall apply when an object has been released through an approved repository, Reports channel, public-safe publication channel, open-source repository, data repository, model repository, learning repository, national repository, or comparable publication pathway. Published status shall be accompanied by metadata, version, license or use condition, support class, public-safe status, correction pathway, and archive rule. Published status shall not constitute approval, public warning, certification, financeability, procurement status, or deployment authorization.

### 2.4.11 Supported.

The supported state shall apply when an object has a recorded support class that provides ongoing or time-limited maintenance, issue handling, correction, documentation, or steward response. Supported status shall be specific to the recorded support class and shall not create warranty, service-level obligation, security certification, provider validation, production readiness, or deployment authorization unless separately contracted outside default DDPGF status.

### 2.4.12 Unsupported.

The unsupported state shall apply when an object is available, recorded, published, listed, or archived without ongoing maintenance or support beyond stated correction or archive channels. Unsupported objects shall carry clear notices to prevent reliance on maintenance, warranty, security updates, compatibility, or current validity. Unsupported status shall not prohibit learning, reuse, citation, or archive use where lawful and clearly bounded.

### 2.4.13 Deprecated.

The deprecated state shall apply when an object remains available but is no longer recommended for new use within its original pathway, has a successor object, is being phased out, has known limitations, or is approaching end-of-support. Deprecation records shall include reason, successor link, migration guidance where applicable, support status, correction status, and archive timeline. Deprecated status shall not mean the object is false, but it shall mean reliance must account for its limited current status.

### 2.4.14 Suspended.

The suspended state shall apply when an object is temporarily restricted due to review, incident, overclaim, security issue, privacy issue, data issue, AI issue, public-safe issue, license issue, protected knowledge issue, safeguard issue, public authority boundary concern, finance boundary concern, procurement boundary concern, provider validation concern, sponsor control concern, consent overclaim, handoff overclaim, or execution overclaim. Suspension may require Marketplace delisting, Registry status update, access restriction, claims freeze, data freeze, technical freeze, handoff pause, or public-safe notice.

### 2.4.15 Corrected.

The corrected state shall apply when an object has undergone a recorded correction, patch, erratum, addendum, revision, metadata fix, public-safe fix, license fix, data fix, model fix, security fix, privacy fix, access-class fix, support-status fix, or boundary notice fix. Corrected status shall include correction history, affected versions, propagation record, and any required public-safe notice, Registry update, Marketplace update, repository release, or handoff recall.

### 2.4.16 Superseded.

The superseded state shall apply when an object has been replaced by a newer, more accurate, more complete, corrected, localized, differently scoped, or otherwise successor object. Superseded objects shall include successor links and archive-not-current notices where applicable. Supersession shall preserve historical record without implying current status.

### 2.4.17 Withdrawn.

The withdrawn state shall apply when an object is removed from active use, publication, listing, release, or handoff routing due to error, rights issue, sensitivity issue, quality issue, overclaim, incident, outdated status, legal concern, public-safe concern, or governance decision. Withdrawal records shall include reason, effective date, affected versions, required notices, and archive handling.

### 2.4.18 Recalled.

The recalled state shall apply when an object previously used, routed, released, listed, or handed off must be actively pulled back, corrected, replaced, or warned against because continued use may cause harm, error, reliance risk, boundary violation, security risk, privacy risk, protected knowledge exposure, public-safe risk, public authority overclaim, finance overclaim, procurement overclaim, consent overclaim, handoff overclaim, or execution overclaim. Recall shall require Registry update, affected-recipient notification where feasible, Marketplace delisting where applicable, repository action where applicable, and handoff recall where applicable.

### 2.4.19 Archived.

The archived state shall apply when an object is preserved for institutional memory, historical reference, traceability, correction history, citation history, successor linkage, legal retention, public-good learning, or audit. Archived objects shall carry archive-not-current notices and access restrictions where required. Archive shall not imply current validity, support, approval, readiness, or authority.

### 2.4.20 Non-continuing.

The non-continuing state shall apply when an object or object pathway will not proceed, will not be maintained, will not be released, will not be listed, will not be published, will not be localized, will not be routed to handoff, or will not be revived absent new intake. Non-continuation shall be recorded to prevent ambiguity, false expectations, orphaned claims, hidden backlog assumptions, or unsupported reliance.

## 2.5 Object Relationships

### 2.5.1 Parent object.

A parent object shall be a higher-level object from which one or more child objects, derived objects, localized objects, translated objects, summaries, dashboards, reports, Studio workflows, Grid inputs, TRL notes, or handoff packages are generated. Parent-object relationships shall preserve lineage, source basis, version relationship, license conditions, data-use labels, AI-use labels, public-safe constraints, sensitivity classes, and correction propagation rules.

### 2.5.2 Child object.

A child object shall be an object created under, from, or within the scope of a parent object. Child objects may include modules, datasets, dashboards, reports, summaries, APIs, models, notebooks, schema extensions, translated versions, localized variants, credential records, proof receipts, or handoff notes. Child objects shall inherit relevant controls from parent objects unless a more restrictive rule applies or an approved review records a different status.

### 2.5.3 Dependency object.

A dependency object shall be any software, data, model, schema, API, license, repository, infrastructure, service, credential, report, ontology, or external source on which another object depends. Dependency objects shall be recorded where material to security, reproducibility, support, licensing, access, public-safe status, handoff, or archive. Dependency drift, vulnerability, withdrawal, license change, or support change may trigger correction, suspension, or archive of dependent objects.

### 2.5.4 Derived object.

A derived object shall be an object created from transformation, aggregation, summarization, extraction, adaptation, model output, dashboard rendering, simulation output, public-safe transformation, localization, translation, fork, or handoff packaging of a source object. Derived objects shall preserve source lineage, rights constraints, data-use labels, AI-use labels, attribution, sensitivity controls, public-safe status, and correction pathways.

A derived object shall not automatically inherit broader permissions than its source. Public-safe derivation shall not release controlled source materials. Model-derived or AI-assisted objects shall identify AI-use and review status where relevant.

### 2.5.5 Forked object.

A forked object shall be a copy, branch, adaptation, or independent continuation of a software, data, model, schema, ontology, documentation, or other digital object. Forked objects shall preserve source attribution, license conditions, version relationship, support distinction, security responsibilities, correction pathways, and fork governance. Forking shall not create endorsement, validation, support obligation, certification, procurement status, or authority for the fork.

### 2.5.6 Localized object.

A localized object shall be an adaptation of a DDPGF object for a national, regional, jurisdictional, linguistic, cultural, accessibility, infrastructure, data-sovereignty, public authority, community, Indigenous protocol-sensitive, or operationally relevant context. Localization may include translation, legal-context notes, terminology adjustments, repository mirroring, access controls, national metadata, local examples, low-bandwidth formats, and public-safe adaptation.

Localization shall not create public authority adoption, legal equivalence, standards adoption, procurement status, financeability, insurability, community consent, Indigenous consent, deployment authorization, or execution authority by implication. Localized objects shall preserve relationship to source objects and shall record differences.

### 2.5.7 Translated object.

A translated object shall be a language-specific or format-specific rendering of a source object. Translation shall preserve source identity, version, scope, license, public-safe status, boundary notices, and correction pathway. Translation review shall be required where meaning affects legal boundaries, public authority language, finance language, procurement language, technical safety, protected knowledge, community safeguards, or public-safe interpretation.

Translation shall not constitute substantive approval, legal localization, public authority adoption, or new license unless separately recorded.

### 2.5.8 Public-safe summary object.

A public-safe summary object shall be a summary, abstract, public report, dashboard view, metadata card, learning note, campaign text, or public-facing explanation derived from one or more source objects after removal, masking, aggregation, simplification, or reframing of sensitive, restricted, protected, public authority-sensitive, cyber-sensitive, geospatial-sensitive, finance-sensitive, procurement-sensitive, or consent-sensitive content.

A public-safe summary object shall not release the controlled source object, shall not create unrestricted rights to underlying data, and shall not imply approval, warning, certification, financeability, procurement status, consent, deployment authorization, or execution authority.

### 2.5.9 Controlled-source object.

A controlled-source object shall be an underlying object or source material that cannot be made openly available due to rights, law, confidentiality, sensitivity, sovereignty, privacy, cyber, infrastructure, community, Indigenous protocol, protected knowledge, public authority, finance, procurement, handoff, or security considerations. Controlled-source objects may support public-safe summaries, metadata-only records, secure-room workflows, data-room workflows, Studio workflows, DRI outputs, Reports, dashboards, or handoff packages.

Controlled-source object restrictions shall travel to derived objects where required. Public reference to a controlled-source object shall not create access rights or disclosure obligations beyond recorded permissions.

### 2.5.10 Handoff-context object.

A handoff-context object shall be a DDPGF object created or packaged to support a lawful downstream actor’s independent diligence, planning, review, implementation consideration, procurement process, finance process, insurance process, public authority process, community process, or execution process outside DDPGF default posture. Handoff-context objects may include evidence, data context, method context, Studio outputs, Grid inputs, TRL notes, safeguard status, public authority dependencies, legal dependencies, finance and insurance questions, provider-neutrality notes, sponsor-boundary notes, recipient responsibilities, correction pathways, and recall pathways.

Handoff-context objects shall transfer context and dependencies, not authority. Recipients shall remain responsible for lawful action, independent review, approvals, finance, insurance, procurement, consent, deployment, operation, and execution.

## 2.6 Object Boundary Notices

### 2.6.1 No-certification notice.

Each DDPGF object shall carry or inherit a no-certification notice where there is any risk that the object could be mistaken for certification, conformance approval, maturity certification, quality certification, AI safety certification, cybersecurity certification, sustainability certification, professional certification, procurement qualification, public authority approval, or deployment approval. The notice shall state in substance that the object is a governed digital public-good object or record within its scope and does not certify any product, provider, project, system, person, organization, jurisdiction, model, dataset, protocol, or implementation unless a separate competent certification process is expressly recorded.

### 2.6.2 No-warranty notice.

Each software, data, model, API, dashboard, notebook, report, learning, repository, infrastructure, or reusable object made available under DDPGF shall carry or inherit a no-warranty notice appropriate to its license, support class, and release status. The notice shall state in substance that availability, publication, listing, download, access, support status, or reuse does not create warranty, service-level commitment, fitness-for-purpose assurance, security guarantee, accuracy guarantee, completeness guarantee, compatibility guarantee, or production-readiness assurance unless separately contracted and recorded.

### 2.6.3 No-procurement notice.

Each Marketplace listing, Registry record, report, software object, dataset, model object, dashboard, credential object, proof receipt, Grid input, TRL note, National Portfolio object, Nexus Universe output, or handoff-context object that could be mistaken for procurement relevance shall carry or inherit a no-procurement notice. The notice shall state in substance that the object does not approve, recommend, validate, rank, shortlist, prequalify, or prefer any provider, vendor, supplier, technology, product, service, project, consortium, National Consortium Company, Project SPV, or implementation actor for procurement purposes.

### 2.6.4 No-finance notice.

Each object that may be viewed by capital readers, insurers, donors, public finance readers, sponsors, enterprises, or handoff recipients shall carry or inherit a no-finance notice where relevant. The notice shall state in substance that the object does not constitute investment advice, solicitation, securities offering, finance approval, financeability determination, bankability determination, donor commitment, public finance allocation, insurance approval, underwriting decision, guarantee, rating, or financial valuation unless separately and lawfully recorded outside DDPGF default status.

### 2.6.5 No-public-authority notice.

Each object that involves public authority learning, policy intelligence, risk intelligence, public-safe reporting, dashboards, DRI indicators, Observatory signals, public authority rooms, National Portfolios, disaster-risk information, early-warning-adjacent information, infrastructure information, health information, or regulatory dependency records shall carry or inherit a no-public-authority notice where relevant. The notice shall state in substance that the object does not constitute public authority decision, public warning, official map, regulatory approval, permit, license, compliance finding, emergency command, public finance action, procurement action, enforcement action, or public authority adoption unless separately issued by a competent public authority.

### 2.6.6 No-consent notice.

Each object involving communities, Indigenous participants where applicable, protected knowledge, local data, place-based knowledge, youth participation, community campaigns, public-interest participation, National Portfolios, safeguards, or handoff contexts shall carry or inherit a no-consent notice where relevant. The notice shall state in substance that participation, contribution, display, listing, publication, translation, localization, public-safe summary, campaign support, or inclusion in a digital object does not create community consent, Indigenous consent, social license, local approval, rights waiver, data permission beyond recorded scope, or implementation authorization.

### 2.6.7 No-deployment notice.

Each software object, model object, AI-agent object, API object, dashboard object, digital twin object, simulation object, Studio workflow object, Grid input, TRL note, infrastructure object, Observatory object, DRI object, reference implementation, or handoff-context object that could be mistaken for deployment readiness shall carry or inherit a no-deployment notice. The notice shall state in substance that demonstration, release, publication, testing, benchmarking, Registry status, Marketplace listing, Studio workflow, Grid input, TRL note, or handoff package does not authorize deployment, production use, operational integration, public authority use, emergency use, infrastructure control, automated decision-making, or implementation.

### 2.6.8 No-execution notice.

Each DDPGF object that could be mistaken for an instruction, command, authorization, implementation step, project approval, operational plan, public authority action, finance action, procurement action, or handoff authorization shall carry or inherit a no-execution notice. The notice shall state in substance that DDPGF objects support public-good knowledge, evidence, learning, discovery, reuse, review, readiness context, and lawful handoff context only; they do not cause Nexus, GCRI, The Global Risks Forum, The Global Risks Alliance, a Nexus body, a national consortium, a public authority participant, a provider, a sponsor, a contributor, a capital reader, an insurer, a community participant, or a handoff recipient to execute any project or assume execution responsibility unless separately and lawfully recorded.


---

# 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/ii.-objects.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.