II. Preparation
2.1 Overview: From Idea to Publication
(a) Strategic Planning and Concept Development
Before drafting any text, contributors should begin with a structured design phase. This involves:
Defining the Intended Purpose and Impact: Identify whether your output is:
A purely academic research study for broad scholarly use.
A scenario plan or corridor action protocol intended for immediate operational deployment.
A policy brief or treaty annex backgrounder for corridor governance or donor negotiations.
A technical artifact, such as a simulation benchmark or a dataset with reproducibility documentation.
Mapping Audience and Stakeholders: Clarify who will consume, apply, or cite this work: fellow researchers, corridor governance boards, NWGs, UN treaty delegates, or local civic councils.
Determining Clause Linkage and Governance Triggers: Decide early whether clause indexing is appropriate. If your output will inform a corridor action trigger, parametric finance release, or treaty scenario pathway, you should plan for direct clause references and ensure your data and scenarios are formatted accordingly.
Verifying Alignment with the Nexus Ecosystem: Confirm which Nexus modules (e.g., NXSCore, NXSGRIx, NXS-DSS) your report interacts with and how it will strengthen the larger multi-module simulation and governance loop.
(b) Research Execution and Drafting
Once your plan is clear:
Conduct Rigorous Data Collection and Analysis: All research must adhere to evidence-based methods. If your work involves Earth observation, AI/ML simulation, or corridor stress testing, keep audit-ready records and code notebooks.
Draft Using Approved Templates: Begin with the GCRI-approved Word or LaTeX templates (Appendix 5.1). These align with the metadata schema and ensure seamless DOI registration on Zenodo.
Observe Narrative and Technical Standards:
Use clear, unambiguous language.
Present data in reproducible formats.
Include figures, maps, and corridor diagrams where relevant.
For scenario reports, provide scenario inputs, constraints, and fallback logic.
Document Generative AI Use Transparently: If you deploy LLMs, automated summarizers, or code generators, record their role and scope meticulously for disclosure in the mandatory AI Use Statement (Section 2.6).
(c) Preparing Metadata and Licensing
Your manuscript is only as findable and enforceable as its metadata and licensing allow:
Complete the Full Nexus Reports Metadata Schema: Include:
Full author list and affiliations.
ORCID IDs for all authors.
Funding acknowledgements and grant numbers.
Project linkages to specific Nexus modules or corridor charters.
Keywords reflecting both research domain and governance use-case.
Clear, concise abstract summarizing the problem, method, findings, and governance implications.
Select an Open License: Use CC BY 4.0 (preferred) unless your NWG or funder mandates a different open license. Closed or restrictive licensing contradicts GCRI’s sovereign open science commitment and is grounds for rejection.
(d) Preparing Supplementary Materials and Supporting Evidence
For a submission to be governance-ready:
Data: Clean, well-labeled data tables in open formats (CSV, GeoJSON, NetCDF) with unit consistency and clear version labels.
Code: Scripts, model source files, or simulation configurations must be well-commented and packaged in a single ZIP, or linked to a public, immutable repository (e.g., GitHub, GitLab).
Visual and Multimedia: High-resolution maps, corridor scenario flowcharts, or dashboard files must comply with Zenodo’s file-type allowances and size constraints (max 50 GB per record).
Clause Reference Matrix (If Applicable): If clause indexing is planned, prepare a clear mapping table showing how report sections or scenario triggers align with corridor clauses or treaty articles.
(e) Pre-Submission Compliance and Internal Review
Before upload:
Run through the Compliance Checklist (Appendix 5.5). Confirm:
Originality: no plagiarism or undisclosed AI-generated sections.
Complete metadata.
Correct open license.
Clause references documented where used.
AI Use Statement attached if any generative systems contributed.
All file formats meet repository requirements.
Conduct Peer or NWG Review:
Scenario plans and policy briefs should undergo informal peer or NWG liaison review to catch gaps and strengthen local relevance.
Finalise Version Control Tags: Label this version clearly (v1.0) and prepare your changelog for future updates.
(f) Upload and Submission
Create or Verify Your Zenodo Account: Link your ORCID ID for identity validation (Section 3.1).
Join the Official Nexus Reports Community: This ensures your report receives a Nexus Reports DOI and governance compliance flag (Section 3.2).
Upload Files, Complete Fields, and Select License: Follow the exact upload sequence to avoid metadata mismatch (Section 3.3).
Assign Clause Indexing (Optional): If relevant, flag clause references in the submission form for NSF tagging.
(g) Editorial Review, DOI Issuance, and Governance Certification
Editorial Board and NWG Liaison Review: Expect metadata validation, licensing audit, and scenario plausibility checks.
Revision Loop (If Required): Respond promptly to any clarifications or required corrections.
Approval and Publication: Once cleared, your work is published with an immutable DOI and visible in the official Nexus Reports community index on Zenodo.
(h) Post-Publication Stewardship
Publication is not the end:
Disseminate Widely: Share the DOI with your NWG, corridor stakeholders, treaty negotiators, and relevant policy circles.
Monitor for Updates: If new data or changing risk conditions arise, update your report using Zenodo’s versioning system, maintaining clear changelogs.
Support Clause Replay: For clause-indexed reports, ensure that corridor planners or treaty bodies can verify and interpret your scenario logic with full version transparency.
Engage with Community Feedback: Respond to post-publication questions or requests for clarifications via the contact channels provided in your metadata.
2.2 Preparing the Manuscript: Structure and Templates
Each Nexus Reports submission must meet dual standards: scientific rigor and clause-compatible operational integrity. This means your report must read not only as a conventional scholarly narrative but as an audit-ready, reusable governance asset, adaptable by corridor planners, NWGs, policy bodies, or parametric risk financiers.
This section explains precisely how to structure your report using the official templates and what each required section must accomplish to ensure metadata alignment, scenario reproducibility, and governance traceability.
(a) Use of Official Templates
Download the standard Word (.docx) or LaTeX (.tex) template (see Appendix 5.1).
Do not modify structural headings, embedded citation styles, or placeholder metadata blocks.
The template ensures your manuscript integrates seamlessly with Zenodo’s DOI indexing and optional clause passport tagging under the Nexus Sovereignty Framework.
(b) Mandatory Core Sections
Every submission must include these elements unless a compelling case for deviation is provided in your cover letter:
1. Title Page
Exact, descriptive title.
Full author list with ORCID iDs.
Institutional affiliations.
Funding sources and grant IDs.
Designated corresponding author’s verified contact email.
2. Abstract
150–300 words.
Clear articulation of:
Context or corridor scenario.
Key methodology.
Principal results.
Governance or policy implications.
Exclude citations.
3. Keywords
4–8 domain-specific terms:
Thematic (e.g., “urban flood forecasting”)
Corridor or scenario type (e.g., “heatwave corridor”)
Relevant Nexus modules (e.g., “NXS-DSS”).
4. Introduction
Problem context.
Gap in current evidence.
Clear statement of objective.
Alignment with corridor priorities or global governance relevance.
5. Methods / Technical Framework
Sufficient for reproduction.
Include:
Data provenance.
Model parameters.
AI/ML pipelines, if used.
Scenario assumptions, fallback logic, and corridor-specific constraints.
For software or simulations, provide code repository links and version tags.
6. Results / Scenario Outputs
Present verifiable outputs.
Use clear tables, maps, and charts.
Explicitly show scenario conditions (e.g., baseline, worst-case).
Where clause indexing applies, label which outputs support which corridor or treaty clause.
7. Discussion
Interpret technical significance.
Highlight governance or policy implications.
Disclose limitations and uncertainty factors.
For scenario reports, discuss possible misuse or misinterpretation risks.
8. Conclusions
Summarize key actionable insights.
Reinforce operational next steps for corridors or treaty partners.
9. Acknowledgements
Recognize funders, local or Indigenous partners, NWG support.
Note corridor charters or treaty instruments if directly referenced.
10. References
Use in-built citation style.
Include DOIs and repository links where available.
Verify all links are persistent.
11. Appendices (Highly Recommended)
Detailed clause matrix (if indexed).
Full scenario input data.
Extended tables, technical manuals, or corridor maps.
(c) Additional Required Elements for Clause-Linked or Scenario Reports
If your report is intended for corridor deployment, treaty annexes, or parametric risk finance, include:
Clause Reference Table: A structured matrix mapping outputs to corridor clause identifiers.
Trigger Logic Description: A concise, plain-language block explaining what scenario condition activates which governance action or payout.
Fallback Logic: An explicit fallback plan for data gaps or sensor failures — critical for corridor scenario resilience.
(d) Use of Generative AI
If generative AI tools contributed to drafting, translation, code generation, or summarization:
Flag the use clearly in the Methods or an Appendix.
Specify the tool(s), version(s), and scope of use.
State the human checks performed to control hallucinations and bias.
(e) Language, Style, and Technical Writing Standards
Use precise, plain English.
Avoid ambiguous or jargon-heavy phrasing — corridor planners and treaty negotiators require interpretability.
Use consistent SI units and clear scenario labels.
Write scenario triggers and fallback clauses in active voice for enforceability.
Maintain a logical flow: each section should support the auditability and operational reuse of the whole.
(f) Common Structural Failures to Avoid
Missing or inconsistent metadata between title page, abstract, and submission form.
Vague scenario descriptions lacking operational thresholds.
Poorly documented methods that cannot be reproduced or externally verified.
Broken or unstable repository links for code or data.
Clause matrix missing for reports that claim scenario governance functionality.
✅ Key Takeaway
A Nexus Reports manuscript is not just an academic paper: it is a legally citable, scenario-ready governance artefact. Clear structure, precise sectioning, consistent version control, and alignment with corridor charters ensure that your work can directly inform treaty backstopping, corridor scenario triggers, or anticipatory funding releases.
2.3 Preparing Metadata and Licensing Information
High-quality metadata and an enforceable open license transform your work from a static document into a trusted, scenario-ready public good that can be cited in corridor charters, embedded in parametric finance contracts, or annexed to international treaties. Within Nexus Reports, metadata is not optional decoration — it is a legal, technical, and governance backbone that must withstand audits, scenario replay, and multilateral treaty referencing years after first publication.
This section provides a complete, step-by-step guide to preparing all required metadata fields and selecting the appropriate open license, so your record is legally sound, FAIR-compliant, clause-compatible, and operationally resilient.
(a) The Role of Metadata in the Nexus Ecosystem
Every metadata element you enter directly supports the four pillars of sovereign governance:
Findability — Governments, NWGs, corridor planners, and treaty signatories must locate scenario-relevant knowledge rapidly using search engines and corridor dashboards.
Interoperability — FAIR-compliant metadata enables automated ingestion into the Nexus modules: e.g., corridor scenario triggers in NXS-EWS, risk benchmarking in NXSGRIx, and decision dashboards in NXS-DSS.
Traceability and Legal Certainty — Metadata anchors your DOI, version history, funding trail, clause index, and licensing conditions, so there is no ambiguity about provenance or permitted use.
Sovereign Resilience — Well-structured metadata ensures that your record remains legally valid and technically reusable if Zenodo or other hosts change or migrate in the future.
(b) Required Metadata Fields — Complete Guide
When uploading to Zenodo, you must complete each required field precisely, matching your manuscript’s content word-for-word. Below is a field-by-field breakdown, plus tips for correctness.
Field
What to Enter
Compliance Notes
Title
The exact, final title from your manuscript.
Do not shorten or paraphrase; corridor dashboards parse this automatically.
Authors
Full list in manuscript order, each with institutional affiliation and verified ORCID iD.
ORCID iDs are required for author credibility and DOI cross-linking.
Description
Paste the Abstract section verbatim.
No LaTeX markup, HTML, or citations. Plain text only.
Keywords
4–8 descriptive keywords.
Must include: (i) main research domain, (ii) corridor/scenario type, (iii) relevant Nexus module(s). Example: flood risk; corridor scenario; NXS-DSS; parametric insurance
.
Publication Date
Date of actual Zenodo submission.
Zenodo auto-dates version updates.
License
Creative Commons Attribution (CC BY 4.0) unless explicitly approved otherwise by the Editor-in-Chief.
Closed or restrictive licenses break clause passport validity and are generally rejected.
Funding
Grant numbers, funder names, corridor funding pool references.
Use the Open Funder Registry ID if available. Example: Global Resilience Fund, Grant #GRF-2025-DRF101
.
Related Identifiers
For updates, input the DOI of the prior version. Also link any code repositories, scenario databases, or supplementary datasets.
Zenodo uses this for version chains and cross-platform citation.
Communities
Select Nexus Reports.
Mandatory — ensures your submission is indexed in GCRI’s sovereign open science cluster.
References
Optional in Zenodo form, but strongly recommended: add main cited works DOIs.
Provides extra discoverability and policy context.
(c) Recommended Advanced Metadata — For Clause and Corridor Use
Add these fields if your report is intended for corridor scenario deployment or treaty annexing:
✅ Nexus Modules: Add a free-text note: e.g., Applicable Nexus Modules: NXSCore, NXSGRIx, NXS-DSS.
✅ Corridor Name: State the precise corridor — e.g., Caribbean Hurricane Corridor 2025–2030
.
✅ Scenario Type: Label clearly: Baseline Forecast
, Stress Test
, Fallback Scenario
, or Parametric Payout Trigger
.
✅ Version Tag: Match the manuscript header. Example: Version: v1.0
.
✅ Clause Passport Declaration: Add to Description:
“This report includes clause-indexed scenario triggers linked to Corridor Charter clauses 2.1–2.3 and Treaty Annex B.”
This ensures downstream systems treat your work as legally traceable within corridor governance and sovereign treaty instruments.
(d) Selecting the Correct License — Non-Negotiable Standards
Why licensing matters: Your license defines whether your report can be reused by corridor stewards, attached to parametric insurance contracts, or cited in a treaty. If licensing is ambiguous, legal enforcement becomes fragile — and the sovereign clause passport is voided.
Required default: ✅ Creative Commons Attribution (CC BY 4.0)
Global standard for open reuse.
Meets UNESCO Open Science and EOSC policy guidelines.
GCRI’s default for sovereign open knowledge assets.
Exceptional cases:
If a corridor charter, national law, or specific donor legally prohibits CC BY, you must obtain written approval from the Editor-in-Chief before submission.
If a scenario contains confidential or embargoed treaty details, you may request a limited-access license — this requires NSF certification and corridor governance approval.
(e) Example Licensing Declaration
Inside your manuscript: Include this statement on the Title Page or final page:
“License: This report is licensed under Creative Commons Attribution 4.0 International (CC BY 4.0). Authors grant GCRI a perpetual, non-exclusive, irrevocable right to host, distribute, and index this work under sovereign open science governance.”
In Zenodo: Select CC BY 4.0 from the drop-down menu.
(f) Provenance and Consistency — Zero-Tolerance for Mismatch
Before finalising your upload, run following compliance test:
✅ Title identical in manuscript and Zenodo field. ✅ Author list identical and in same order, with ORCID iDs cross-checked. ✅ Abstract pasted verbatim, no edits. ✅ Keywords logically match corridor and module tags. ✅ Funding in Zenodo matches Acknowledgements in manuscript. ✅ License in Zenodo matches in-manuscript declaration. ✅ Related Identifiers linked for version chains and external repositories.
Any mismatch slows approval and weakens your report’s clause passport chain-of-custody.
✅ Key Takeaway
Correct metadata and licensing protect your intellectual rights, guarantee open public reuse, and operationalise your report as a live, clause-compatible governance asset within the Nexus Ecosystem’s sovereign risk architecture.
2.4 Preparing Supplementary Materials (Data, Code, Media)
In the Nexus Reports framework, supplementary materials are not optional add-ons — they are integral proof of reproducibility, operational readiness, and clause-level traceability. Each dataset, code archive, scenario output, or visual explainer must be prepared to withstand corridor audits, legal scrutiny in parametric finance contexts, and reuse by future treaty parties.
This section provides a clear, enforceable guide for packaging, documenting, and uploading your supplementary files to meet sovereign governance standards and Zenodo repository constraints.
(a) What to Include
Prepare the following, as relevant to your report type:
Datasets:
All raw and processed input data driving your analysis or scenario.
For corridor risk or hazard models, include complete time series and input assumptions.
Source Code & Algorithms:
All scripts, notebooks, configuration files, and automation pipelines used to generate results.
Include any post-processing code for maps or scenario visualisation.
Scenario Outputs & Visuals:
Tables of results, stress test conditions, corridor scenario maps.
Parametric payout triggers and fallback results, if modelled.
Multimedia or Interactive Assets:
Short explanatory videos.
Participatory corridor maps or interactive dashboards in HTML or embeddable format.
(b) Preferred Formats — Governance-Ready Standards
Type
Approved Formats
Rationale
Data
.csv
, .tsv
, .json
, .geojson
, .netcdf
Machine-readable, non-proprietary, easy to parse across modules.
Code
.py
, .R
, .ipynb
, .zip
(multi-file)
Readable by open-source tools; zipped archives must include README.
Outputs
.csv
(numeric), .json
(structured), .pdf
(print maps), .html
(interactive dashboards)
Matches corridor dashboard ingest standards.
Multimedia
.mp4
(video), .png
or .svg
(figures)
Compressed for streaming and open distribution.
(c) Naming Conventions and Version Labelling
All filenames must follow a clear, durable structure to avoid misinterpretation by corridor nodes:
Use descriptive base names + corridor ID + version: Example:
IndusFlood_ScenarioData_v1.csv
Example:ParametricPayoutModel_v1.0.py
Inside README files: state precise build version, date of last run, and any dependencies.
Use ZIP archives: if you have multiple files for a code module or dataset, compress into one well-labelled ZIP and include a manifest inside.
(d) Required Documentation for Each File
For corridor or treaty reuse, each file must be self-explanatory:
Include at minimum:
README.md for Code & Data:
What the file is for.
How to run it or parse it.
Required software versions and libraries.
Expected output and any runtime parameters.
Data Dictionary for Datasets:
Column names.
Units (use SI).
Allowed value ranges.
Explanation of missing data treatment.
Code Comments:
Inline comments in scripts or notebooks are mandatory.
Reference scenario IDs or corridor names consistently.
(e) Clause-Indexed Reports — Additional Files
If your report supports clause indexing for corridor governance or treaty annexing, your supplements must include:
✅ Clause Reference Matrix:
A table mapping scenario outputs to the exact corridor clauses they validate.
Format:
.csv
or.xlsx
, easy for corridor scenario planners to parse.
✅ Trigger Condition Note:
Short
.pdf
or.txt
explaining under what conditions the scenario activates a clause-based governance response or parametric payout.
✅ Fallback Simulation Logic:
If your corridor scenario includes fallback simulations (e.g., alternative hazard estimate if a sensor fails), include code and a short note describing when to use it.
(f) Zenodo Upload: File Sequence and Metadata Linkage
When uploading your submission:
1️⃣ Main manuscript file first — labelled clearly, e.g., Manuscript_v1.pdf
.
2️⃣ Each supplementary file next — use same base naming as in your text references.
3️⃣ ZIP archives for multiple code scripts — label them clearly: Caribbean_Hurricane_Model_v1.zip
.
4️⃣ Link all external repositories under Related Identifiers
. For example:
GitHub repo for version-controlled code.
Separate Zenodo DOI for large external datasets.
5️⃣ Cross-check that all filenames cited in your manuscript exactly match the uploaded files — mismatches slow governance validation and can break clause replay chains.
(g) File Size, Compression, and Integrity
Zenodo limit: Max 50 GB per record. If you exceed, split across multiple linked records.
Use lossless compression for ZIP archives (
.zip
preferred over.rar
).Do not password-protect archives.
Verify ZIPs extract correctly and all README files are intact before upload.
(h) Compliance Failures to Avoid
🚫 Proprietary file formats (e.g., .xlsx
without .csv
version; .sav
SPSS files).
🚫 Missing README or unclear column definitions.
🚫 Un-commented code with cryptic variable names.
🚫 Inconsistent scenario naming between files and manuscript.
🚫 Uploading raw confidential data — anonymise or aggregate sensitive inputs first.
✅ Key Operational Reminder
Your supplementary files are not only proof of science — they are legal backstops for corridor triggers, payout verifications, and treaty dispute resolutions. Treat them as sovereign-grade governance artefacts: clear, durable, versioned, and auditable under the Nexus Sovereignty Framework.
2.5 File Format Guidelines and Repository Constraints
Every Nexus Reports submission must strictly follow the approved file format standards and repository rules set by GCRI and Zenodo. Correct file preparation guarantees that all data, code, scenario outputs, and multimedia remain legally reusable, technically durable, and clause-compatible for corridor triggers, treaty annexes, or parametric finance settlement.
This section is your definitive technical checklist: use it to avoid upload rejections and protect your scenario’s long-term operational integrity.
(a) Approved File Formats
Use only these formats for each type of file:
File Type
Allowed Formats
Why
Manuscript
.pdf
Final version, matching template, for DOI archiving.
Tabular Data
.csv
, .tsv
Open, non-proprietary, machine-readable.
Structured Data
.json
, .geojson
, .netcdf
For spatial grids, hazard cubes, or multi-dimensional scenario data.
Code & Scripts
.py
, .R
, .ipynb
, .m
(if open MATLAB alt provided)
Fully commented, reusable by corridor planners.
Code Packages
.zip
only
Multiple files or modules compressed with README.md.
Static Maps & Figures
.png
, .svg
, .pdf
Vector preferred for corridor maps.
Interactive Dashboards
.html
+ assets zipped
Test offline before upload.
Video / Audio
.mp4
, .webm
(video); .mp3
(audio)
Compressed, narration clear for participatory corridors.
✅ Best practice: Always pick open formats over proprietary ones — this preserves sovereign data portability.
(b) Compression and Archiving Rules
1. Archive Standard:
Use
.zip
exclusively for multi-file packages.Do not use
.rar
,.7z
, or password-protected archives.
2. Folder Structure inside ZIP:
Organise with clear subfolders:
/data/
,/code/
,/outputs/
,/docs/
.Include a root-level
README.md
describing each folder’s purpose.
3. Test Extraction:
Extract your ZIP locally to verify it opens cleanly on all operating systems.
Fix broken links or missing README before upload.
(c) Repository File Size Limits
Zenodo’s constraints:
Max per record: 50 GB (total, all files).
Recommended per file: keep individual files under 2–5 GB for stable upload.
For very large datasets:
Split logically by corridor region or time period.
E.g.,
Hurricane_2025_Region1.csv
,Region2.csv
Document split logic in README.
For extremely large or live datasets, link an external certified node and connect its DOI in Zenodo under
Related Identifiers
.
(d) File Naming and Versioning Best Practice
1. Filename Conventions:
Always include:
Corridor name
Scenario ID
Version tag
✅ Example: Caribbean_Hurricane_Model_v1.0.py
✅ Example: IndusFlood_ScenarioData_v1.csv
2. Fallback or Contingency Files:
Add
_Fallback
or_Contingency
:E.g.,
IndusFlood_ScenarioData_Fallback_v1.csv
Clarify its usage in the README.
3. Version Updates:
Never create a new record for updates.
Use Zenodo’s New Version button to update.
Only upload files that changed — leave unchanged files alone.
In Zenodo’s version description, state exactly what was updated:
“Updated 2026 input data; bug fix in stress test script; all outputs rerun with new assumptions.”
Zenodo preserves a single concept DOI — older versions stay citable for corridor audit.
(e) Checksums for Large Files
For files >5 GB:
Generate a checksum (
.sha256
or.md5
).Upload the checksum as a
.txt
alongside the main file, or include it in the ZIP.
✅ Example:
IndusFlood_ScenarioData_v1.csv
IndusFlood_ScenarioData_v1.csv.sha256
This allows corridor operators to independently verify file integrity years later.
(f) Prohibited Files and Practices
🚫 Do NOT submit:
Proprietary formats with no open version (
.xls
instead of.csv
;.sav
SPSS files).Compiled binaries (
.exe
) without source code.Password-protected or encrypted ZIPs or PDFs.
Raw personal or sensitive data that violates privacy or corridor treaty rules.
All uploaded files must pass GCRI digital sovereignty compliance — misuse may trigger immediate rejection or governance sanction.
(g) Automated Repository Checks
Zenodo runs:
MIME type validation — only standard, safe formats accepted.
Virus scan — infected files are blocked.
Metadata match — title, author list, license must align with uploaded files.
✅ Double-check before you click Publish:
No unexpected file extensions.
No duplicates or inconsistent version tags.
Each file has an accompanying README or inline documentation.
(h) Final Compliance Checklist
Before final upload, confirm: ✅ All files use approved, open formats. ✅ Multi-file code/data packages are ZIP only, with clear subfolders and README.md. ✅ All filenames match your manuscript text exactly. ✅ Fallback/contingency files clearly named. ✅ Checksums included for files >5 GB. ✅ Used New Version to update, not a new record. ✅ No encryption, no password locks. ✅ Total record size below 50 GB.
✅ Key Principle
Your file bundle is more than data — it is the sovereign audit trail for corridor scenario replay, parametric finance settlement, and treaty annex referencing. Open formats, version integrity, clear structure, and verified checksums ensure your record remains trusted and enforceable for decades.
2.6 Writing an AI Use Statement (If Applicable)
Nexus Reports requires all contributors to maintain the highest standards of research integrity and operational transparency in line with GCRI’s Trustworthy AI Governance Charter (see Appendix X). Any use of generative AI must be explicitly disclosed so that corridor scenario triggers, fallback simulations, and treaty annexes remain auditable and clause-verifiable for years to come.
(a) When You Must Declare AI Use
You are required to prepare an AI Use Statement if any generative AI system or tool was used for any part of your work, including:
✅ Drafting narrative sections (abstract, introduction, discussion). ✅ Generating or debugging code or data transformation scripts. ✅ Creating synthetic datasets to supplement real corridor data. ✅ Using automatic translation or summarisation for substantial text. ✅ Generating scenario visuals, corridor maps, or explanatory diagrams.
Strict prohibition: Do NOT use generative AI to produce actual corridor forecasts, stress test numerical outputs, or risk estimates. Use only validated scientific models and simulation engines for scenario computation.
If you are unsure whether your usage requires disclosure — always disclose. Transparency preserves corridor trust and treaty enforceability.
(b) What the AI Use Statement Must Include
Your statement must be precise, factual, and verifiable. At minimum, it must cover:
Tool name and version — e.g., “OpenAI GPT-4o, April 2025.”
Exact scope of use — which parts of the manuscript or code were AI-assisted.
Human oversight and verification — how you ensured factual accuracy, clause alignment, and scenario realism.
Clause passport control — for reports with clause indexing, confirm that all scenario triggers and fallback conditions were manually validated by a qualified human author.
(c) Recommended Standard Format
Insert this as a short paragraph at the end of your Methods section, or as a separate Appendix for major usage:
AI Use Statement: “This report includes content drafted or refined with assistance from OpenAI GPT-4o (April 2025) for narrative flow, scenario description phrasing, and code snippet generation. All AI-assisted material was reviewed, fact-checked, and revised by the authors to ensure scenario realism and corridor trigger correctness. All clause linkages were human-validated for operational deployment under GCRI’s Trustworthy AI Governance Charter.”
For multiple tools, list each by name and version, and clarify its role.
(d) How to Declare AI Use in Zenodo
When uploading to Zenodo:
After your abstract in the Description field, add: “AI Use: This submission includes AI-assisted content. Full disclosure and verification steps are documented in the manuscript’s AI Use Statement.”
Keep it short in metadata — the authoritative statement lives in the manuscript PDF.
(e) Best Practices for Trustworthy Disclosure
✅ Always cross-check AI-generated facts and references; LLMs may embed training bias or hallucinate sources. ✅ Confirm the AI’s training cutoff does not conflict with the corridor scenario timeframe — update facts with the latest data where needed. ✅ Store AI prompts and session logs securely, where possible, to help corridor auditors or treaty partners verify reproducibility. ✅ Never rely on generative AI for final scenario forecasts or numerical stress tests — use only validated simulation models under NXSCore or certified modules.
(f) Correcting Oversights
If you realise after submission that you used AI but did not disclose it:
Notify the Nexus Reports Editor-in-Chief immediately.
Update your manuscript and version record with a proper AI Use Statement.
Use Zenodo’s New Version function to ensure a clean audit trail.
Prompt self-correction is treated favourably and protects your clause passport status.
(g) Enforcement and Consequences
Failure to disclose AI use transparently is a serious breach of GCRI’s sovereign open science standards and corridor scenario integrity. Consequences may include:
Suspension of publication rights under Nexus Reports.
Revocation of the report’s clause passport, nullifying corridor scenario enforceability.
Public retraction notice linked to the DOI.
✅ Key Principle
A clear, truthful AI Use Statement is your guarantee that your contribution can be trusted by corridor operators, national working groups, parametric insurers, treaty negotiators, and future governance auditors. It demonstrates leadership in responsible AI and protects the public good mission of the Nexus Ecosystem.
2.7 Pre-Submission Compliance Checklist
Before you hit Publish in Zenodo, use this authoritative checklist to confirm your submission meets Nexus Reports and GCRI sovereign governance standards.
This protects your corridor scenario’s clause passport, version control chain, and future treaty validity.
(a) Core Manuscript Requirements
✅ Title, authors, affiliations, and ORCID iDs are complete and match Zenodo form exactly. ✅ Abstract is clear, 150–300 words, no citations. ✅ Keywords include domain, corridor, scenario type, and Nexus module tags. ✅ Manuscript follows standard template structure (Intro, Methods, Results, Discussion, Conclusions). ✅ Acknowledgements list funding, NWGs, or local partners accurately. ✅ References are correctly formatted and up to date.
(b) Metadata and License
✅ Title, author list, and abstract in Zenodo exactly match manuscript. ✅ Keywords field matches what’s in manuscript front matter. ✅ License set to CC BY 4.0 (or approved exception only). ✅ Funding field completed with grant numbers and funder names. ✅ Nexus Reports Community selected in Zenodo. ✅ Related Identifiers link prior versions or code repos if applicable.
(c) Files and Supplementary Materials
✅ All data is open format: .csv
, .json
, .geojson
, .netcdf
.
✅ Code scripts are well-commented, zipped if multi-file, with README.md
.
✅ Visuals/maps are .png
, .svg
or .pdf
.
✅ Fallback/contingency scenario files clearly named: ..._Fallback_v1.csv
.
✅ Large files (>5 GB) have checksum file (.sha256
or .md5
) attached.
✅ Total upload size within Zenodo’s 50 GB limit.
✅ ZIPs extract correctly, no password locks.
(d) AI Use Statement (if used)
✅ Confirm whether any generative AI was used. ✅ If yes:
AI Use Statement included in manuscript per Section 2.6.
Short AI note added in Zenodo’s Description field.
Prompts/session logs stored securely for audit if practical.
(e) Clause Indexing (If Used)
✅ Clause Matrix uploaded (.csv
or .xlsx
).
✅ Scenario triggers and fallback logic explained in manuscript.
✅ All linkages verified by a human author.
(f) Version Control
✅ All file names include corridor, scenario ID, and version tag (e.g., IndusFlood_v1.csv
).
✅ If updating, used Zenodo’s New Version — not a new record.
✅ Related Identifiers link back to prior DOIs.
(g) Final Confirm
✅ No proprietary, encrypted, or locked files.
✅ No placeholder names like data1.csv
or final.docx
.
✅ README.md included for all code ZIPs.
✅ ZIP structure clear: /data/
, /code/
, /outputs/
, /docs/
.
✅ Key Reminder
This checklist is your binding self-certification that your submission is clause-compatible, corridor-ready, and audit-proof.
Once published, your DOI becomes part of GCRI’s sovereign knowledge chain — use it responsibly.
2.8 Common Mistakes and How to Avoid Them
Despite good intentions, many otherwise strong Nexus Reports submissions are delayed or rejected due to preventable errors. These issues can compromise clause passport integrity, break corridor scenario triggers, or block Zenodo DOI indexing — costing time and weakening the governance trust chain.
This section lists the most frequent pitfalls, explains why they matter, and shows exactly how to prevent them.
(a) Metadata Mismatches
Issue:
Title, author list, or abstract in Zenodo do not exactly match the manuscript.
Why it matters:
Breaks DOI record integrity.
Causes confusion in corridor dashboards and clause traceability.
How to avoid: ✅ Copy-paste title and abstract exactly. ✅ Double-check author order and ORCIDs.
(b) Incomplete or Closed Licensing
Issue:
Upload uses “All Rights Reserved” or custom restrictive license.
License does not match what the manuscript states.
Why it matters:
Violates GCRI’s sovereign open science principle.
Makes the scenario legally unusable for corridor actions or treaty annexes.
How to avoid: ✅ Always choose CC BY 4.0 unless you have formal written exemption from the Editor-in-Chief. ✅ Confirm license line in manuscript and Zenodo match.
(c) Improper File Formats
Issue:
Upload includes proprietary or unreadable files (.xlsx, .sav, .exe).
Password-protected or encrypted ZIPs.
Why it matters:
Breaks open FAIR standards.
Corridor scenario engines cannot parse proprietary formats automatically.
Password locks block Zenodo virus scan.
How to avoid:
✅ Use open formats: .csv
, .json
, .geojson
, .zip
.
✅ Test files open in standard open-source tools.
✅ Never encrypt or password-protect files.
(d) Weak Version Control
Issue:
File names have no scenario ID or version tag (e.g., “data.csv”, “final.docx”).
Updates uploaded as entirely new Zenodo records instead of New Version.
Why it matters:
Confuses corridor scenario replay pipelines.
Breaks chain-of-custody for treaty or parametric finance verification.
How to avoid:
✅ Use structured file names: CorridorName_ScenarioID_v1.csv
.
✅ Always use New Version in Zenodo for updates.
(e) Missing or Poorly Documented Supplementary Files
Issue:
No
README.md
in code ZIP.No data dictionary for large datasets.
Clause Matrix or Fallback Logic missing for scenario reports.
Why it matters:
Corridor planners cannot validate or reuse your scenario.
Weakens the clause passport’s enforceability.
How to avoid:
✅ Every ZIP has README.md
.
✅ All datasets have clear column definitions.
✅ Clause Matrix is attached if clause indexing is used.
(f) Unclear or Missing AI Disclosure
Issue:
Used generative AI but did not declare it.
Vague AI statement with no tool version or scope.
Why it matters:
Violates the Trustworthy AI Governance Charter.
May trigger retraction, scenario passport suspension.
How to avoid: ✅ If any AI used: include a complete AI Use Statement per Section 2.6. ✅ Add a short note in Zenodo’s Description field.
(g) Upload Errors or Oversized Record
Issue:
Total upload exceeds Zenodo’s 50 GB limit.
Large files lack a checksum.
ZIP archive corrupted or fails to extract.
Why it matters:
Blocks final publish button.
Can break corridor dashboard import.
How to avoid:
✅ Check total size. Chunk large datasets logically.
✅ Attach .sha256
for files >5 GB.
✅ Test ZIP locally: extract on a fresh machine to confirm.
✅ Your Zero-Error Rule
Before hitting Publish in Zenodo: Every file must be open, properly named, versioned, documented, and legally reusable. Every metadata field must mirror your manuscript. Every corridor scenario must remain auditable, reproducible, and clause-verified.
If you follow the Pre-Submission Compliance Checklist (2.7) and double-check this Mistake List (2.8), your DOI will be corridor-ready, treaty-compatible, and trusted by GCRI stakeholders worldwide.
2.9 Recommended Style and Citation Standards
Each Nexus Reports submission must meet the highest standards of writing clarity, technical accuracy, and citation integrity. Reports are not read solely by academics: they inform corridor planners, treaty negotiators, parametric finance stakeholders, and sovereign audit teams. Clear language and disciplined referencing ensure your work is operationally enforceable and trusted under the Nexus Sovereignty Framework.
This section codifies the style, structure, and citation requirements all contributors must follow.
(a) Use Clear, Direct Language
Write in precise, plain English.
Avoid unnecessary jargon. Define all technical terms at first mention.
Use active voice for scenario conditions and triggers.
Example (preferred): “Operators deploy the model when rainfall exceeds 200 mm.”
Example (to avoid): “The model is deployed when conditions are met.”
Keep sentences concise, ideally averaging 20–25 words.
Use consistent corridor and scenario IDs throughout the document, tables, figures, and file names.
(b) Maintain Consistent Terminology
Use a single, clear term for each concept throughout.
For instance, do not switch from “Caribbean Hurricane Corridor 2025–2030” to “Hurricane Project Area” partway through the report.
If referring to a clause or corridor scenario condition, replicate the official wording from the charter to maintain clause passport validity.
(c) Apply Standard Structure and Formatting
Use the official Nexus Reports Word or LaTeX template.
Include standard sections: Introduction, Methods, Results, Discussion, and Conclusions.
Avoid custom fonts, non-standard colors, or excessive formatting.
Number all tables and figures sequentially and include clear, descriptive captions.
Cross-reference every table and figure in the main text.
(d) Use Consistent Units and Numerical Conventions
Use SI units consistently (e.g., mm, °C, km/h).
Spell out numbers from zero to nine; use numerals for 10 and above.
Use a period for decimals (e.g., 3.14) — not a comma.
Report uncertainty clearly for key thresholds, for example: “Rainfall ≥ 200 ± 10 mm.”
(e) Write Precise Scenario Conditions
For clause-indexed corridor scenarios, write each trigger condition in plain, unambiguous language.
Correct: “Trigger activates when the 7-day mean rainfall exceeds 250 mm in Region A.”
Vague: “Trigger may occur when rainfall seems high.”
Describe fallback conditions explicitly, so corridor planners know what to do if primary sensors fail.
(f) Follow Rigorous Citation Practice
Use the built-in citation style embedded in the official template.
Cite published work with DOIs where possible.
For datasets and code repositories, cite the DOI or a stable, versioned URL.
For corridor charters or treaties, cite the exact clause ID and include a link if public.
Examples:
In-text: Smith et al. (2024) demonstrate that...
Clause reference: ...in line with Caribbean Corridor Charter Clause 2.1.
Reference list: Smith J, Doe A. (2024). Risk Modelling for Island States. Nexus Reports. DOI: doi.org/xxxxxx
(g) Disclose AI Use Appropriately
If generative AI assisted with text drafting, code, or visuals, include a clear AI Use Statement in your manuscript (see Section 2.6).
Do not list AI systems as “authors.”
Do not cite AI tools as primary sources; cite the factual or peer-reviewed sources you validated through human oversight.
(h) Language Quality and Proofreading
Carefully check spelling, grammar, and flow.
Seek review by a native English speaker or your NWG liaison if needed.
Never rely solely on AI grammar checkers for final validation; human review is required.
(i) Use Acronyms Properly
Spell out all acronyms at first use.
Example: Early Warning System (EWS)
Avoid excessive acronyms; prioritize readability for corridor operators and policy reviewers.
(j) Respect Originality and Citation Ethics
Write in your own words. Directly quote corridor charter clauses or treaty language only where exact reproduction is necessary.
Cite your own prior publications properly, including DOI and version information.
Use plagiarism detection tools if possible; GCRI reserves the right to run random checks.
A well-written, clearly cited report is not just good scholarship — it is the foundation for corridor scenario trust, clause passport validity, and enforceable, sovereign-grade knowledge governance. Always write so that corridor planners, auditors, and treaty partners can reuse and verify your work with full confidence.
2.10 Final Review and Internal Peer Checks
Before you upload your manuscript and supporting files to Zenodo for Nexus Reports, you must conduct a final peer-level or NWG liaison review. This step is not merely an academic courtesy — it is a practical safeguard that ensures your report meets corridor operational standards, clause passport integrity, and GCRI’s sovereign open science commitments.
This section outlines the objectives, process, and documentation requirements for this last-stage check.
(a) Why a Final Review is Mandatory
Corridor scenario reports, policy briefs, and clause-indexed triggers can directly affect:
Parametric payouts under corridor risk finance pools
Corridor governance decisions during real climate or hazard events
Treaty negotiation stances and sovereign funding allocations
A single oversight — such as a hidden metadata error, an ambiguous scenario condition, or a mismatched file version — can undermine corridor trust and lead to costly legal or governance disputes. A structured peer check mitigates these risks.
(b) Who Should Conduct the Peer Check
Ideally, select a qualified colleague with domain knowledge in your scenario topic (e.g., hydroclimate risk, urban resilience modelling, food security corridors).
For corridor scenario reports or clause-indexed outputs, also involve your National Working Group (NWG) liaison if possible.
Do not rely on the co-authors alone; use a fresh pair of eyes to catch blind spots.
(c) What the Reviewer Should Verify
Your internal reviewer should independently confirm:
Completeness
All core sections (Introduction, Methods, Results, Discussion, Conclusions) are present and logically consistent.
All scenario data, code, and fallback logic files are attached.
Technical Accuracy
Data sources and units are correct and reproducible.
Scenario thresholds match corridor charter wording.
AI Use Statement (if applicable) is complete and factually truthful.
Compliance
File formats follow approved open standards.
Metadata in the manuscript matches what you will enter in Zenodo.
Licensing is CC BY 4.0 or formally approved exception.
Scenario Logic
Clause triggers are clear, testable, and fallback scenarios are documented.
Clause Matrix matches manuscript content.
Fallback conditions make practical sense for corridor operations.
Clarity and Readability
No ambiguous language or contradictory terms.
Acronyms are spelled out at first use.
Figures and tables are properly captioned and referenced in text.
(d) How to Document the Internal Check
After review, record in your project notes:
Reviewer name and affiliation.
Date of review.
Any final issues found and how they were resolved.
If requested by the Editor-in-Chief or an NWG, be prepared to provide this check record as evidence during corridor scenario certification.
(e) Common Peer Check Best Practices
Provide your reviewer with the entire package: manuscript draft, supplementary files (data, code, fallback logic), and a copy of your Pre-Submission Compliance Checklist (Section 2.7).
Allow at least 2–3 days for a careful read-through.
Encourage honest critique: a robust corridor scenario depends on catching small oversights early.
Do not make last-minute changes to files after peer check without re-confirming consistency.
(f) Final Author Responsibility
Remember:
The peer check does not transfer responsibility — you, as the submitting author, remain fully accountable for accuracy, integrity, and clause passport compliance.
The final version must reflect the peer check outcomes exactly.
A careful internal peer check is the last line of defense for governance-grade trust. It ensures your research is not just valid today but legally usable and operationally reliable for corridor planners and treaty signatories in the years ahead.
Last updated
Was this helpful?