# XI. PUBLICATIONS

## 11.1 Publication Object Doctrine

### 11.1.1 Report object defined.

A **Report Object** under the Distributed Digital Public Goods Framework means a governed digital-public-good publication object that translates evidence, methods, datasets, software, models, ontologies, schemas, dashboards, digital twins, simulations, Studio workflows, National Portfolio records, Nexus Universe outputs, Foundry builds, Campaign records, Academy records, Observatory signals, DRI outputs, GRIx mappings, Grid inputs, TRL notes, handoff context, correction records, or archive records into a structured, reviewable, citable, public-safe, controlled, or restricted publication form. A Report Object may be issued as a public report, controlled report, technical note, data paper, software release paper, public-safe summary, methodological note, field note, repository package, learning report, readiness note, correction report, archive report, or handoff context note.

A Report Object shall be treated as a lifecycle-governed digital public-good object, not merely as a static document. It shall carry object identity, version, steward, source pathway, evidence basis, review status, publication class, repository location, license class, citation format, public-safe status, sensitivity status, data-use label, AI-use label where applicable, support class, correction pathway, withdrawal pathway, archive rule, and boundary notices. A Report Object may support learning, transparency, reuse, public-safe knowledge, institutional memory, national portfolio formation, standards-interface discipline, and lawful handoff literacy, but shall not create approval, certification, procurement status, financeability, insurability, public authority decision, public warning, community or Indigenous consent, deployment authorization, or execution authority by implication.

### 11.1.2 Data paper defined.

A **Data Paper** means a publication object that describes a dataset, data product, metadata object, data pipeline, data dictionary, schema, codebook, feature set, benchmark dataset, DRI dataset, Observatory dataset, National Portfolio dataset, synthetic dataset, public-safe dataset, controlled dataset, or metadata-only record. A Data Paper shall explain the purpose, source class, collection or generation method, rights status, data-use label, AI-use label, lineage, quality notes, limitations, sensitivity class, access class, public-safe transformation, repository location, citation guidance, correction pathway, and archive rule for the relevant data object.

A Data Paper shall not create unrestricted data access, reuse permission beyond the recorded license and rights status, public authority record status, protected knowledge permission, community consent, Indigenous consent, data transfer authorization, AI training authorization, procurement qualification, financeability, or operational reliance by implication. Where the underlying data object is restricted, controlled, secure-room-only, metadata-only, protected, community-sensitive, Indigenous protocol-sensitive, geospatial-sensitive, health-sensitive, youth-sensitive, cyber-sensitive, infrastructure-sensitive, or public authority-sensitive, the Data Paper shall be limited to public-safe or controlled description and shall not expose the restricted data itself.

### 11.1.3 Software release paper defined.

A **Software Release Paper** means a publication object that describes a software object, repository, library, service, application, dashboard, API, SDK, connector, adapter, command-line tool, notebook package, infrastructure-as-code template, test suite, reference implementation, Studio component, Registry component, Marketplace component, DRI component, Observatory component, Grid component, or public-good technical baseline. A Software Release Paper shall record purpose, scope, architecture, repository location, version, license, maintainers, dependencies, SBOM status where applicable, security review status, test status, accessibility status, documentation status, support class, known limitations, release class, correction pathway, deprecation pathway, and archive rule.

A Software Release Paper shall not create warranty, production approval, security certification, procurement recommendation, provider validation, public authority approval, deployment authorization, operational command, service-level commitment, financeability, insurability, or execution authority by implication. Reference implementations shall be described as reference implementations only, and shall not be presented as certified production systems unless separately and lawfully certified by an appropriate competent actor outside the default DDPGF posture.

### 11.1.4 Technical note defined.

A **Technical Note** means a bounded publication object that explains a method, architecture, protocol object, standards-interface mapping, data workflow, AI workflow, model card, system card, benchmark card, API profile, schema, ontology, digital twin, simulation, Studio workflow, Grid input, TRL note, repository pattern, secure-room workflow, compute-to-data workflow, public-safe release method, correction method, or handoff dependency. Technical Notes may be public, controlled, internal, secure-room-only, or handoff-recipient-only depending on sensitivity and intended use.

A Technical Note shall identify its intended audience, scope, evidence basis, assumptions, limitations, dependencies, review status, version, author or steward, repository or Registry link, public-safe status, and boundary notices. A Technical Note shall not be treated as certification, conformance approval, legal standard, public authority guidance, procurement guidance, financial advice, insurance advice, deployment authorization, safety approval, or execution instruction by default.

### 11.1.5 Public-safe summary defined.

A **Public-Safe Summary** means a publication object that translates a more detailed, controlled, technical, sensitive, or restricted object into a form suitable for public or semi-public release without exposing restricted data, protected knowledge, sensitive locations, security-sensitive information, operational vulnerabilities, privacy-sensitive information, public authority-sensitive information, community-sensitive information, Indigenous protocol-sensitive information, commercially sensitive information, or unsafe technical detail. Public-Safe Summaries may summarize reports, data papers, software releases, models, dashboards, Studio workflows, DRI outputs, Observatory outputs, National Portfolio records, Campaign records, Nexus Universe outputs, Grid inputs, TRL notes, or handoff context.

A Public-Safe Summary shall preserve material caveats, uncertainty, scope limits, no-warning language, no-approval language, no-certification language, no-procurement language, no-finance language, no-consent language, no-deployment language, no-execution language, and correction pathways. Public-safe release shall not imply that the underlying object is open, unrestricted, verified for all uses, approved for deployment, approved by a public authority, financeable, insurable, procurement-ready, or suitable for reliance outside recorded scope.

### 11.1.6 Repository package defined.

A **Repository Package** means a governed publication package deposited, stored, versioned, or linked through Zenodo, comparable repositories, Git repositories, data repositories, model repositories, national repositories, controlled repositories, secure repositories, Nexus repositories, or metadata-only records. A Repository Package may include report files, README files, metadata, licenses, citation files, changelogs, data availability statements, AI-use statements, support statements, no-conversion notices, related identifiers, source files, reproducibility materials, notebooks, software release files, model cards, system cards, benchmark cards, schema files, API specifications, public-safe summaries, and correction pathway records.

A Repository Package shall be structured for reuse, citation, review, correction, archive, and institutional memory while preserving access controls and boundary notices. Repository deposit shall not convert an object into unrestricted public property, certified evidence, public authority approval, procurement status, provider validation, financeability, insurability, deployment authorization, or execution authority by implication.

### 11.1.7 DOI as citation infrastructure.

A **Digital Object Identifier** or comparable persistent identifier shall be treated as citation infrastructure, not authority infrastructure. A DOI may support durable reference, version traceability, repository discoverability, citation, academic interoperability, object lineage, public-good memory, and correction linkage. A DOI may be assigned to reports, data papers, software release papers, technical notes, public-safe summaries, repository packages, datasets, software releases, learning objects, model cards, system cards, benchmark cards, schemas, ontologies, or other citable DDPGF objects where appropriate.

A DOI shall not create approval, endorsement, certification, peer-review status, legal validity, public authority adoption, procurement eligibility, financeability, insurability, safety approval, deployment authorization, data reuse right, open license, or execution authority. DOI assignment shall be accompanied by metadata, version, license, access class, support class, correction pathway, archive rule, and no-conversion notice.

### 11.1.8 Publication without authority by implication.

Publication under DDPGF shall make objects visible, citable, reusable, reviewable, correctable, and discoverable within recorded scope. Publication shall not convert an object into a public authority act, legal standard, regulatory guidance, certification, procurement recommendation, finance signal, insurance signal, community consent, Indigenous consent, deployment approval, operational command, public warning, provider validation, sponsor endorsement, institutional endorsement, or execution authorization by implication.

The governing publication rule shall be **publish for learning, evidence, reuse, and accountability; preserve boundaries for authority, reliance, procurement, finance, consent, deployment, and execution**. Any downstream use requiring legal authority, public authority action, procurement action, professional reliance, financial reliance, insurance reliance, data permission, community consent, Indigenous consent, clinical use, emergency use, operational deployment, or enterprise execution shall require a separate competent process outside default publication status.

## 11.2 Report Object Classes

### 11.2.1 National Portfolio Reports.

A **National Portfolio Report** means a publication object that summarizes national systems-risk context, National Portfolio priorities, National Challenge Briefs, National Working Group outputs, Competence Cell outputs, DRI contributions, Observatory needs, WFEH-B priorities, public authority learning questions, Campaign signals, Foundry build needs, Studio workflow needs, Grid inputs, TRL notes, Nexus Universe preparation, and lawful handoff dependencies for a national context. It shall be nationally grounded, locally contextualized, public-safe, correctionable, and clearly bounded.

A National Portfolio Report shall not rank countries, compare national competence in a punitive manner, imply public authority endorsement, create procurement status, create financeability, create public warning, grant implementation authority, or override national ownership. Where public authority participation is recorded, the report shall distinguish learning participation from official decision-making.

### 11.2.2 WFEH-B Reports.

A **WFEH-B Report** means a publication object addressing water, food, energy, health, biodiversity, nature, and related cross-system dependencies, cascades, resilience needs, digital public-good objects, data gaps, DRI indicators, Observatory signals, Studio scenarios, National Portfolio needs, and handoff dependencies. WFEH-B Reports may support public-safe understanding of systemic risks, resilience pathways, adaptation needs, public-good technology opportunities, data commons, and national capability formation.

A WFEH-B Report shall not create environmental certification, health determination, resource allocation decision, public authority approval, procurement status, financeability, insurability, operational instruction, or consent to intervene in affected communities or ecosystems.

### 11.2.3 DRR Reports.

A **Disaster Risk Reduction Report** means a publication object addressing hazard exposure, vulnerability, resilience capacity, risk reduction needs, preparedness, prevention, mitigation, public-safe communication, early-warning interface dependencies, national and regional DRI needs, Campaign pathways, Academy learning needs, Foundry builds, Studio scenarios, Observatory signals, and lawful handoff dependencies. DRR Reports may support learning, planning literacy, public-good knowledge, and evidence formation.

A DRR Report shall not be a public warning, emergency order, evacuation instruction, official hazard notice, public authority decision, compliance determination, disaster declaration, or operational command. Any official warning or emergency action remains outside DDPGF publication status and must be issued by competent public authorities.

### 11.2.4 DRF Reports.

A **Disaster Risk Finance Report** means a publication object addressing finance-readiness questions, protection gaps, risk layering, resilience investment logic, insurance-readiness questions, public finance relevance, donor-readiness questions, capital-readability, diligence gaps, assumptions, dependencies, and handoff context. DRF Reports shall support literacy, readiness, structured questioning, and non-reliance learning.

A DRF Report shall not constitute financial advice, investment advice, insurance advice, underwriting, credit analysis, rating, bankability determination, donor commitment, guarantee, public finance allocation, securities offering, solicitation, transaction recommendation, or financeability determination.

### 11.2.5 DRI Reports.

A **Disaster Risk Intelligence Report** means a publication object summarizing DRI indicators, signal records, hotspot records, cascade records, confidence labels, uncertainty labels, dashboard records, national DRI contributions, correction records, and public-safe intelligence summaries. DRI Reports shall preserve uncertainty and avoid overclaim.

A DRI Report shall not be a public warning, rating, insurance score, investment signal, country ranking, emergency command, official risk determination, or public authority decision. Any public release shall include public-safe limitations and correction pathways.

### 11.2.6 DICE Reports.

A **DICE Report** means a publication object addressing Data Commons, Innovation Commons, Software Commons, Knowledge Commons, secure rooms, data rooms, clean rooms, compute-to-data workflows, metadata practices, data-use labels, AI-use labels, data rights, commons governance, and digital-public-good object stewardship. DICE Reports may include public-safe summaries of controlled data infrastructure without exposing restricted data.

A DICE Report shall not create data access rights, unrestricted reuse rights, data transfer authorization, AI training permission, protected knowledge permission, public authority record status, or deployment authority by implication.

### 11.2.7 GRIx Reports.

A **GRIx Report** means a publication object addressing risk ontology, controlled vocabulary, taxonomies, semantic interoperability, risk categories, WFEH-B categories, DRR categories, DRF categories, DRI categories, frontier technology risk categories, safeguard categories, handoff dependency categories, localization, translation, and semantic correction. GRIx Reports shall support shared meaning, not legal determination.

A GRIx Report shall not create legal classification, rating, regulatory category, public authority determination, standards authority, insurance classification, investment classification, procurement classification, or certification by implication.

### 11.2.8 Observatory Reports.

An **Observatory Report** means a publication object addressing Observatory nodes, hubs, regional clusters, national dense Nexus cores, edge signals, sensor networks, geospatial signals, Earth observation signals, digital twin needs, degraded-mode awareness, public-safe observability outputs, and correction records. Observatory Reports shall describe signals within recorded scope and sensitivity controls.

An Observatory Report shall not create surveillance authority, public warning, intelligence authority, public authority decision, operational command, location disclosure permission, or deployment authorization. Sensitive geospatial, infrastructure, community, cyber, and protected knowledge controls shall apply.

### 11.2.9 Foundry Reports.

A **Foundry Report** means a publication object addressing BuildGrid programs, tracks, quests, bounties, builds, maintainers, public-good production, micro-production, evidence outputs, release classes, quality gates, support status, correction loops, and handoff dependency packages. Foundry Reports may document progress, outputs, gaps, learning, and continuation pathways.

A Foundry Report shall not convert Foundry output into certified product, procurement-ready solution, provider validation, deployment-ready system, enterprise execution, investment opportunity, or public authority-approved implementation.

### 11.2.10 Campaign Reports.

A **Campaign Report** means a publication object addressing Campaign purposes, public-safe messages, signatures, pledges, support records, volunteer records, Campaign DICE contributions, Campaign DRI contributions, Working Group formation records, Competence Cell formation records, Nexus Universe routing, correction records, and archive records. Campaign Reports may support civic learning, public-good mobilization, and accountability.

A Campaign Report shall not treat signatures as votes, pledges as binding finance, support as control, volunteers as employees, public attention as public authority approval, community participation as consent, donor interest as commitment, or Campaign success as execution authority.

### 11.2.11 Academy Reports.

An **Academy Report** means a publication object addressing Nexus Academy pathways, Risk Academy pathways, learning objects, courses, modules, micro-credentials, WILPs, learner records in aggregate or public-safe form, competency maps, learning outcomes, accessibility, inclusion, translation, learner feedback, and correction. Academy Reports may support capability formation and learning transparency.

An Academy Report shall not create professional licensing, employment eligibility, certification status, public authority credential, procurement qualification, immigration status, wage guarantee, or hiring decision by implication.

### 11.2.12 Labs Reports.

A **Labs Report** means a publication object addressing research questions, evidence gaps, testbed records, method notes, datasets, model cards, system cards, benchmark records, scenario records, public-safe summaries, research impact records, and Foundry transfer records. Labs Reports may support research translation and public-good R\&D.

A Labs Report shall not create approval, deployment authorization, public authority decision, certification, financeability, insurability, community consent, or endorsement by implication. Dual-use, protected knowledge, privacy, data, AI, and public-safe controls shall apply.

### 11.2.13 Risk Agency Reports.

A **Risk Agency Report** means a publication object addressing expert routing, advisory support, risk advisory, resilience consulting support, public-safe reporting support, capacity-building support, cross-sphere translation, handoff support, engagement records, output records, and correction records. It may be public, controlled, client-specific, internal, or handoff-recipient-only depending on engagement scope.

A Risk Agency Report shall not create execution authority, certification, professional licensing, investment advice, insurance advice, public authority decision, community consent, or deployment authorization by implication. Any reliance status shall be expressly recorded and bounded.

### 11.2.14 Nexus Universe Reports.

A **Nexus Universe Report** means a publication object addressing annual surge outputs, arena records, participation records, Core Build records, public authority learning records, readiness question records, support records, Marketplace listings, Registry updates, Campaign updates, Foundry continuation records, National Portfolio updates, handoff dependency notes, correction records, and archive records. It shall preserve the distinction between visibility, participation, learning, readiness, and lawful handoff.

A Nexus Universe Report shall not treat attendance as endorsement, arena visibility as approval, public authority presence as public authority decision, sponsor presence as control, provider demonstration as validation, capital-reader participation as finance, insurance-reader participation as underwriting, or Universe output as execution.

### 11.2.15 Grid and TRL Reports.

A **Grid and TRL Report** means a publication object addressing Grid inputs, bounded readiness evidence, TRL 1–10 notes, review routing, evidence sufficiency, method sufficiency, data sufficiency, AI-use sufficiency, cyber sufficiency, public-safe sufficiency, safeguard sufficiency, support sufficiency, reproducibility sufficiency, correction sufficiency, downgrade, suspension, withdrawal, reinstatement, and handoff recall. It shall preserve assurance without certification.

A Grid or TRL Report shall not create maturity certification, procurement readiness, financeability, insurability, public authority approval, deployment authorization, general validation, or execution authority.

### 11.2.16 Handoff context notes.

A **Handoff Context Note** means a publication or controlled release object that summarizes evidence context, data context, method context, Studio context, Grid context, TRL context, public-safe status, safeguard status, public authority dependencies, legal dependencies, finance and insurance questions, procurement boundaries, provider-neutrality notes, sponsor-boundary notes, recipient responsibilities, correction pathways, recall pathways, and archive rules for potential lawful downstream use.

A Handoff Context Note shall transfer context and dependencies, not authority. It shall not authorize execution, deployment, procurement, finance, insurance, public authority action, provider selection, community consent, Indigenous consent, or operational command.

### 11.2.17 Correction and archive reports.

A **Correction and Archive Report** means a publication object that records correction, addendum, supersession, withdrawal, retraction where necessary, recall, public repair, archive, non-continuation, correction propagation, affected object lists, successor objects, dependency impacts, and public-safe notices. It shall preserve institutional memory and trustworthiness.

A Correction and Archive Report shall not erase the need for separate lawful actions by competent authorities, downstream users, repositories, recipients, or implementing actors. It shall make the correction record visible within scope and support safe discontinuation or replacement.

## 11.3 Repository Strategy

### 11.3.1 Zenodo deposits.

DDPGF may use Zenodo deposits for citable, persistent, versioned, open-science-aligned publication of reports, datasets, software releases, technical notes, public-safe summaries, repository packages, learning objects, model cards, system cards, benchmark cards, schemas, ontologies, notebooks, and other appropriate digital public-good objects. Zenodo deposits shall include complete metadata, license information, citation guidance, versioning, related identifiers, public-safe notices, support statements, correction pathways, and no-conversion notices.

Zenodo deposit shall not imply that an object is unrestricted, certified, peer reviewed, approved by a public authority, procurement-ready, financeable, insurable, safe for deployment, or authorized for execution. Sensitive, controlled, restricted, protected, or secure-room-only materials shall not be deposited openly except as metadata-only records or public-safe summaries where approved.

### 11.3.2 Comparable repositories.

DDPGF may use comparable repositories for domain-specific, institutional, national, technical, educational, data, software, model, or open-science publication where those repositories better fit object class, jurisdiction, audience, rights status, preservation needs, technical requirements, or access controls. Comparable repositories may include academic repositories, data repositories, software archives, institutional repositories, national repositories, open educational resource repositories, model repositories, standards-interface repositories, or controlled-access repositories.

Repository selection shall consider persistence, metadata quality, access controls, DOI or persistent identifier availability, licensing, versioning, correction support, withdrawal support, archive reliability, jurisdictional fit, accessibility, cost, public-safe requirements, and national localization needs.

### 11.3.3 Git repositories.

Git repositories shall be used for software objects, documentation objects, schema objects, API specifications, notebooks, reproducibility packages, templates, infrastructure-as-code, issue tracking, changelogs, release notes, contribution workflows, maintainer workflows, and correction workflows where version-controlled collaboration is appropriate. Git repositories shall include README files, license files, contribution guidance, code of conduct where applicable, security policy where applicable, citation files where appropriate, changelogs, support statements, public-safe documentation, and release tags.

Git repository availability shall not create warranty, deployment authorization, security certification, procurement recommendation, provider validation, or production readiness by implication. Public repositories shall not contain secrets, restricted data, protected knowledge, sensitive geospatial details, unsafe operational instructions, or unauthorized third-party materials.

### 11.3.4 Data repositories.

Data repositories shall be used for datasets, metadata records, public-safe data, data dictionaries, codebooks, schemas, benchmark datasets, data papers, DRI datasets, Observatory datasets, National Portfolio datasets, and controlled data descriptions where appropriate. Data repositories shall support metadata, license or rights statements, data-use labels, AI-use labels, lineage, quality notes, access class, sensitivity class, public-safe transformation notes, citation guidance, correction pathways, and archive rules.

Data repository publication shall not create unrestricted data rights, permission to reuse beyond recorded terms, permission to train AI systems, public authority record status, protected knowledge permission, community consent, Indigenous consent, data transfer authorization, or handoff permission by implication.

### 11.3.5 Model repositories.

Model repositories shall be used for model cards, system cards, benchmark cards, evaluation harnesses, model objects, AI system objects, simulation models, digital twin models, forecasting models, classifiers, retrieval-augmented system descriptions, agentic workflow records, and controlled model documentation where appropriate. Model repositories shall include intended use, prohibited use, data provenance, training data constraints, evaluation records, bias and harm review, human review requirements, AI-use labels, incident pathways, withdrawal pathways, and archive rules.

Model repository publication shall not create AI safety certification, general validation, public authority approval, deployment authorization, automated decision authority, financeability, insurability, procurement readiness, or execution authority.

### 11.3.6 National repositories.

National repositories shall support national ownership, localization, national portfolio memory, national language access, national data sovereignty, national public-safe reporting, national learning objects, national DRI contributions, national Observatory records, national software adaptations, national schemas, national public authority learning records, and national handoff context where appropriate. National repositories may be open, controlled, restricted, secure, metadata-only, or public-safe depending on the relevant national context and object class.

National repository placement shall not imply public authority approval, national endorsement, legal status, procurement status, public finance allocation, deployment authorization, community consent, or execution authority. National repository governance shall preserve national ownership without enabling national gatekeeping abuse, exclusion, capture, or silent alteration of common Nexus semantics.

### 11.3.7 Controlled repositories.

Controlled repositories shall be used for objects requiring restricted access, including controlled data, sensitive methods, public authority-sensitive materials, cyber-sensitive materials, infrastructure-sensitive materials, health-sensitive materials, youth-sensitive materials, community-sensitive materials, Indigenous protocol-sensitive materials where applicable, protected knowledge, legal-sensitive materials, handoff-recipient-only materials, or pre-publication objects. Controlled repositories shall apply identity and access management, role-based permissions, logging, review controls, export controls, retention rules, correction workflows, and archive controls.

Controlled access shall not create entitlement to reuse, download, disclose, transfer, publish, rely upon, deploy, procure, finance, insure, or execute the object. Access shall remain purpose-limited and revocable according to the applicable record.

### 11.3.8 Secure repositories.

Secure repositories shall be used for high-sensitivity objects requiring enhanced security controls, including secure-room materials, protected knowledge records, critical infrastructure-sensitive information, cyber-sensitive records, security-sensitive code, restricted AI workflows, public authority-sensitive records, confidential partner records, controlled handoff packages, and materials subject to legal hold or incident response. Secure repositories shall apply heightened access controls, encryption where appropriate, audit logs, no-download restrictions where required, output review, incident monitoring, and archive sealing where appropriate.

Secure repository access shall not create data rights, public authority approval, handoff permission, operational authority, deployment authorization, or execution authority. Secure repository materials may require public-safe summaries or metadata-only records for broader ecosystem memory.

### 11.3.9 Metadata-only records.

A **Metadata-Only Record** shall be used where the existence, identity, description, stewardship, version, access class, sensitivity class, or citation of an object can be recorded without exposing the underlying object. Metadata-only records may apply to restricted data, protected knowledge, controlled models, secure-room workflows, sensitive geospatial information, cyber-sensitive materials, infrastructure-sensitive materials, public authority-sensitive records, handoff-recipient-only packages, or archived materials.

A metadata-only record shall not imply that the underlying object is open, accessible, reusable, approved, validated, certified, or safe for deployment. It shall preserve discoverability and memory while protecting sensitive content.

### 11.3.10 Repository community governance.

Repository community governance shall define who may deposit, review, update, correct, withdraw, curate, archive, list, link, or steward objects within a repository community. Repository community governance may include maintainer roles, reviewer roles, steward roles, contributor roles, release roles, security roles, public-safe review roles, data steward roles, AI review roles, safeguard review roles, and archive roles.

Repository community governance shall preserve role separation, conflict management, provider neutrality, sponsor boundary discipline, public authority boundary discipline, finance boundary discipline, procurement neutrality, public-safe release, correctionability, and archive integrity. Community governance shall not create certification authority, standards authority, public authority, procurement authority, finance authority, or execution authority by implication.

## 11.4 Publication Package Contents

### 11.4.1 Report file.

A Publication Package shall include the primary report file or equivalent publication file in an approved format suitable to the release class, repository requirements, accessibility requirements, preservation requirements, and audience. The report file may be provided as PDF, HTML, Markdown, text, notebook, structured data, presentation, dataset documentation, software release paper, technical note, public-safe summary, or other approved publication format.

The report file shall include title, version, date, steward, scope, public-safe status, citation guidance where applicable, license or rights statement, boundary notices, correction pathway, and archive notice. The report file shall not include restricted materials unless the release class permits access and controls.

### 11.4.2 Metadata.

Publication metadata shall include title, description, creators or stewards, contributors where appropriate, institution, object class, keywords, domain tags, Nexus pillar linkage, mechanism linkage, date, version, language, jurisdictional context, license, access class, sensitivity class, public-safe status, data-use label, AI-use label, related identifiers, repository location, review status, support class, correction pathway, and archive rule.

Metadata shall be accurate, public-safe, non-misleading, and correctionable. Metadata shall not overstate certification, approval, authority, endorsement, financeability, procurement relevance, or deployment readiness.

### 11.4.3 README.

A README shall describe the package contents, object purpose, intended audience, scope, structure, use instructions, citation instructions, license or rights status, support class, public-safe limitations, known limitations, related objects, correction pathway, and archive status. For software, data, model, API, notebook, or reproducibility packages, the README shall also include installation, access, environment, dependency, data, AI-use, or execution notes as applicable.

README content shall be clear, accessible, and boundary-disciplined. It shall distinguish learning, research, public-good, controlled, and handoff-context use from production deployment or execution.

### 11.4.4 License.

A Publication Package shall include a license file or rights statement identifying permitted uses, restrictions, attribution requirements, derivative-use permissions, redistribution rules, commercial-use status, data-use limits, AI-use limits where applicable, and jurisdictional limitations where applicable. Where no open license is granted, the package shall clearly state restricted rights, controlled access, or all-rights-reserved status as applicable.

A license shall not override privacy law, data protection, community safeguards, Indigenous protocols where applicable, protected knowledge controls, public authority restrictions, cyber-sensitive restrictions, export controls, contractual restrictions, or repository terms.

### 11.4.5 Citation file.

A Citation File shall provide preferred citation format, authors or stewards, title, version, date, DOI or persistent identifier where available, repository location, related identifiers, and access date guidance where appropriate. Citation files may use recognized citation metadata formats where suitable.

Citation guidance shall support attribution and traceability. Citation shall not imply approval, endorsement, validation, certification, authority, permission to reuse beyond license, or reliance.

### 11.4.6 Changelog.

A Changelog shall record material changes, version updates, corrections, additions, removals, public-safe transformations, license changes, support status changes, dependency changes, review status changes, data changes, AI-use changes, security changes, deprecations, withdrawals, supersessions, and archive actions. Changelogs shall be clear enough to support auditability and downstream correction.

Where a publication package affects other DDPGF objects, the changelog shall identify dependent objects or related records requiring update, review, or correction propagation.

### 11.4.7 Data availability statement.

A Data Availability Statement shall identify whether data exists, whether it is included, where it is located, what access class applies, what license or rights status applies, what data-use label applies, what AI-use label applies where relevant, whether restricted data was used, whether public-safe transformation occurred, whether metadata-only records are provided, and how access may be requested where lawful and appropriate.

A Data Availability Statement shall not create data access rights, reuse permission, AI training permission, download permission, cross-border transfer permission, protected knowledge permission, community consent, Indigenous consent, or handoff permission.

### 11.4.8 AI-use statement.

An AI-Use Statement shall disclose whether AI tools, AI models, automated systems, agentic workflows, machine-learning models, retrieval systems, summarization tools, classification tools, evaluation tools, or generative systems were used in creating, analyzing, reviewing, translating, transforming, or publishing the object. It shall identify the general class of use, human review status, data-use limits, output review status, known limitations, and AI-use label where applicable.

An AI-Use Statement shall not imply that AI-generated or AI-assisted outputs are automatically correct, validated, certified, safe, unbiased, approved, or suitable for reliance. Human review and correctionability shall remain central.

### 11.4.9 Support statement.

A Support Statement shall define whether the object is supported, unsupported, experimental, reference-only, archival, deprecated, maintained, community-maintained, institutionally maintained, secure-room-supported, handoff-recipient-supported, or non-continuing. It shall identify support channels, maintainer or steward contact where appropriate, issue reporting, security reporting, correction reporting, and response expectations where applicable.

Support status shall not create warranty, service-level agreement, professional duty, procurement eligibility, production readiness, deployment authorization, or reliance right unless separately contracted or legally recorded.

### 11.4.10 No-conversion notice.

A Publication Package shall include a no-conversion notice stating that publication, citation, repository deposit, DOI assignment, Marketplace listing, Registry record, technical review, data availability statement, AI-use statement, support statement, Grid input, TRL note, Studio workflow, public-safe summary, or handoff context does not create certification, public authority approval, procurement status, financeability, insurability, warranty, deployment authorization, consent, endorsement, or execution authority by implication.

The no-conversion notice shall be visible, plain, and consistent with the object class.

### 11.4.11 Related identifiers.

Related identifiers shall link the Publication Package to prior versions, successor versions, related reports, datasets, software releases, model cards, system cards, benchmark cards, schemas, ontologies, API specifications, Studio workflows, Registry records, Marketplace listings, Grid inputs, TRL notes, Nexus Universe outputs, National Portfolio objects, proof receipts, correction notices, withdrawal notices, archive records, and handoff context notes where applicable.

Related identifiers shall support traceability and correction propagation. Linkage shall not imply endorsement, equivalence, validation, certification, or authority across related objects unless separately recorded.

### 11.4.12 Correction pathway.

Each Publication Package shall include a Correction Pathway identifying how errors, outdated content, unsafe language, broken links, licensing issues, data issues, AI-use issues, accessibility issues, security issues, public-safe issues, protected knowledge issues, overclaims, or boundary incidents may be reported, reviewed, corrected, withdrawn, superseded, retracted, recalled, or archived. Correction Pathways shall identify responsible stewards, reporting channels, review process, status update mechanism, and propagation expectations.

Correction pathways shall remain active for the life of the object and, where feasible, after archive.

## 11.5 Public-Safe Publication Controls

### 11.5.1 No-warning language.

Publications shall avoid language that presents DDPGF outputs, DRI outputs, Observatory outputs, dashboards, indicators, scenarios, simulations, digital twins, reports, public-safe summaries, or National Portfolio records as official warnings, alerts, evacuation instructions, emergency declarations, operational commands, hazard determinations, or public authority notices. Where hazard, risk, exposure, vulnerability, resilience, or crisis information is discussed, the publication shall state that competent public authorities retain authority for official warnings and emergency action.

No-warning language shall be especially clear for DRR Reports, DRI Reports, Observatory Reports, Studio scenarios, dashboards, digital twins, WFEH-B Reports, National Portfolio Reports, and Campaign materials.

### 11.5.2 No-approval language.

Publications shall avoid language that implies approval, endorsement, validation, authorization, adoption, regulatory acceptance, public authority approval, community approval, Indigenous approval, institutional approval, or downstream recipient approval unless such approval is separately and lawfully recorded by a competent actor. Review, publication, repository deposit, citation, DOI assignment, Registry record, or Marketplace listing shall not be described as approval.

No-approval language shall apply to all object classes, especially technical notes, model cards, software releases, data papers, public authority learning guides, National Portfolio Reports, and handoff context notes.

### 11.5.3 No-finance language.

Publications shall avoid language that implies investment advice, financeability, bankability, insurability, underwriting, donor commitment, public finance allocation, guarantee, securities offering, creditworthiness, insurance score, capital commitment, lender approval, investor interest, or transaction readiness. Finance-readiness and capital-readability may be discussed only as bounded questions, assumptions, dependencies, diligence gaps, literacy, or no-reliance context.

No-finance language shall be mandatory for DRF Reports, handoff context notes, Grid and TRL Reports, National Portfolio Reports, Marketplace listings, and Nexus Universe outputs involving capital readers, insurers, donors, or public finance readers.

### 11.5.4 No-procurement language.

Publications shall avoid language that implies procurement recommendation, preferred supplier status, vendor validation, tender support, supplier approval, product qualification, technology selection, purchasing instruction, or procurement framework status. Software releases, technical notes, Marketplace listings, provider contributions, reference implementations, dashboards, APIs, and handoff context shall be described neutrally.

No-procurement language shall preserve provider neutrality, sponsor boundary discipline, public-good firewall, and independent diligence requirements.

### 11.5.5 No-certification language.

Publications shall avoid language that implies certification, maturity certification, conformity certification, AI safety certification, security certification, environmental certification, professional certification, data certification, model validation, general validation, standards conformance certification, or official quality approval unless separately and lawfully recorded by a competent certifying actor. Review, testing, benchmark results, Grid inputs, TRL notes, Registry status, and technical notes shall be described as bounded evidence or review status only.

No-certification language shall be mandatory for Grid and TRL Reports, Software Release Papers, Model Commons publications, DRI publications, GRIx publications, learning and credential publications, and standards-interface technical notes.

### 11.5.6 No-consent language.

Publications shall avoid language that implies community consent, Indigenous consent, social license, stakeholder approval, affected-community endorsement, protected knowledge permission, or permission to implement in a place or community unless consent is separately and lawfully recorded through appropriate protocols. Participation, consultation, attendance, contribution, learning, Campaign support, public-safe review, or community guide creation shall not be treated as consent.

No-consent language shall be mandatory for community-facing reports, WFEH-B Reports, Observatory Reports, geospatial outputs, National Portfolio Reports, Campaign Reports, public authority learning outputs, and handoff context notes.

### 11.5.7 No-execution language.

Publications shall avoid language that implies DDPGF, NAF, SCF, Nexus Foundry, Nexus Universe, Nexus Reports, Nexus Marketplace, Nexus Registry, Nexus Studio, Nexus Grid, Nexus Observatory, DICE, GRIx, DRI, GCRI, The Global Risks Forum (GRF), The Global Risks Alliance (GRA), or any public-good Nexus institution is executing projects, deploying systems, operating infrastructure, commanding emergency response, procuring solutions, financing projects, underwriting risk, or implementing enterprise delivery by default.

No-execution language shall state that lawful implementation, deployment, procurement, financing, insurance, operation, or enterprise execution must occur separately through competent actors and recorded pathways.

### 11.5.8 Protected knowledge controls.

Publications shall protect knowledge that is culturally sensitive, community-sensitive, Indigenous protocol-sensitive, security-sensitive, cyber-sensitive, infrastructure-sensitive, geospatial-sensitive, health-sensitive, youth-sensitive, ecological-sensitive, commercially sensitive, legally restricted, or otherwise unsuitable for public release. Protected knowledge shall be excluded, masked, generalized, aggregated, transformed, restricted, or held in controlled repositories as appropriate.

Public-safe summaries may describe the existence of protected knowledge controls without revealing protected knowledge. Publication shall not convert protected knowledge into open knowledge or grant reuse permission.

### 11.5.9 Sensitive geospatial controls.

Publications containing geospatial, location, infrastructure, ecological, biodiversity, community, facility, sensor, edge-node, Observatory, disaster-risk, cyber-physical, or digital twin information shall apply sensitive geospatial controls. These may include masking, aggregation, generalization, delayed release, restricted resolution, omission of exact coordinates, protected species controls, critical infrastructure controls, community safety controls, and controlled-access routing.

Geospatial publication shall not create surveillance authority, location disclosure permission, operational targeting, public warning, public authority decision, or deployment authorization.

### 11.5.10 Public repair.

Where a publication creates confusion, overclaim, harm, misinterpretation, unsafe reliance, protected knowledge exposure, public authority boundary error, finance boundary error, procurement boundary error, certification boundary error, consent boundary error, data error, AI-use error, cyber exposure, or execution overclaim, public repair shall be initiated. Public repair may include correction notices, addenda, revised public-safe summaries, withdrawal notices, repository updates, Registry updates, Marketplace delisting, DOI metadata updates, notification to affected users, and archive status changes.

Public repair shall prioritize clarity, harm reduction, affected-party notice where appropriate, correction propagation, and preservation of institutional trust.

## 11.6 Publication Boundary Rules

### 11.6.1 Publication is not approval.

Publication of any DDPGF object, Report Object, Data Paper, Software Release Paper, Technical Note, Public-Safe Summary, Repository Package, Learning Object, model card, system card, benchmark card, dashboard, Studio workflow, Grid input, TRL note, or handoff context note shall not constitute approval by GCRI, The Global Risks Forum (GRF), The Global Risks Alliance (GRA), any Nexus institution, public authority, standards body, funder, insurer, capital reader, sponsor, provider, community, Indigenous institution, National Consortium Company, Project SPV, or downstream actor unless separately and expressly recorded.

### 11.6.2 DOI is not authority.

Assignment of a DOI or other persistent identifier shall support citation, discoverability, traceability, versioning, and archive, but shall not create authority, endorsement, validation, certification, legal status, public authority adoption, procurement status, financeability, insurability, data reuse right, deployment authorization, or execution authority.

### 11.6.3 Open access is not unrestricted use.

Open access to a publication shall not mean unrestricted use of underlying data, software, models, images, geospatial information, protected knowledge, trademarks, third-party materials, community knowledge, Indigenous knowledge, confidential information, or controlled objects. Use shall remain subject to license terms, rights statements, data-use labels, AI-use labels, sensitivity controls, attribution duties, public-safe restrictions, and applicable law.

### 11.6.4 Report is not public warning.

No DDPGF report, DRI report, Observatory report, dashboard, simulation, digital twin, scenario, public-safe summary, Campaign report, National Portfolio report, or Nexus Universe report shall be treated as an official public warning, emergency alert, evacuation instruction, disaster declaration, hazard order, public authority notice, or operational command. Official public warnings and emergency actions remain within competent public authority processes.

### 11.6.5 Technical note is not certification.

A Technical Note may document methods, protocols, interfaces, software, data workflows, model workflows, benchmarks, tests, standards-interface questions, or readiness evidence, but it shall not constitute certification, conformance approval, security approval, AI safety approval, professional approval, regulatory approval, procurement qualification, production approval, or deployment authorization by default.

### 11.6.6 National Portfolio Report is not country ranking.

A National Portfolio Report shall support national ownership, systems understanding, public-good capability formation, learning, readiness, and lawful handoff context. It shall not be used as a country ranking, credit rating, investment ranking, insurance ranking, political ranking, compliance ranking, procurement ranking, donor allocation score, public finance allocation score, or public authority performance judgment by default.


---

# 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/xi.-publications.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.