CEOS Zenodo Submission Guide

3. Create an account and join the community

Only members can submit to the CEOS community, so set this up first.

1. Create a Zenodo account at zenodo.org/signup. You can sign up with ORCID, with GitHub, or with a Zenodo username and password. CEOS recommends ORCID. It ties the account to your author identity and supports two-factor sign-in, which plain Zenodo accounts do not.
2. Confirm your email address. Zenodo does not let you upload anything until you do.
3. Ask for membership. Email the Technical Coordinator with your Zenodo username or account email, the CEOS entity you are submitting for, and the document you plan to submit.
4. Accept the invitation. Zenodo emails it to you, and it also appears under “Requests” in your Zenodo dashboard. The community cannot receive your submission until you accept.

Membership is per person, not by institution. If you submit on someone else’s behalf, you need your own account and membership.

If this is your first submission, you may practice in the Zenodo sandbox first. It works like the real site, but be advised its DOIs never resolve and its contents can be wiped at any time. It needs a separate account, and nothing made there can be moved across. Work through Sections 4 and 5 there, stopping before “Submit for review”.

Zenodo’s own help shows the screens in more detail: creating an account, creating an upload and submitting to a community for review.

4. Prepare the document

The published file is the text that received status, under the CEOS cover page for that status, with its own DOI printed on the cover. You may create the draft before status is conferred, but you will need to upload the file twice.

• When you create the draft, upload the document as it went to Principals, and reserve its DOI.
• When status is conferred, replace that file with the text that received status, under the status cover page with the DOI printed on it.

If Principals accepted changes before conferring status, the text that received status is the one they reviewed and approved, with those changes. Nothing has been published yet, so this is not a new version.

4.1 The status cover page

CEOS uses different cover pages for Endorsed and Acknowledged documents. The templates are on the CEOS website at [URL TBD]. You prepare the cover page, and the Technical Coordinator checks it against the CEOS status decision before publication.

• Use the cover page for the status Principals actually conferred, which may differ from the one you requested.
• Print the DOI as a full link, for example https://doi.org/10.5281/zenodo.NNNNNNN

4.2 Reserve the DOI

Zenodo can reserve a draft’s DOI before publication, so that you can print it on the cover page.

1. In the draft, find “Do you already have a DOI for this upload?” and answer “No”. If your document already has a DOI, stop here and read Section 8.
2. Click “Get a DOI now!”. Zenodo shows the DOI it has reserved.
3. Note the DOI. You print it on the status cover page when status is conferred (Section 6.3).

A reserved DOI does not resolve until the record is published. If status is never conferred, the DOI is never registered. Do not delete the draft while your request is open. Deleting it cancels the reservation, and you would need a new DOI. Each new version reserves its own DOI (Section 7.2).

4.3 The file

• Upload the document as a single PDF, and mark it as the default preview so that it opens on the record page.
• PDF/A is preferred, because it is designed for long-term preservation. In Word on Windows, choose “Save As”, then PDF, then the PDF/A option under “Options”. In Acrobat Pro, choose “Save as Other”, then “Archivable PDF (PDF/A)”. Google Docs, Word for Mac, Preview and Acrobat Reader cannot create PDF/A. The free veraPDF validator (verapdf.org) checks the result.
• The final PDF must have its fonts embedded, and no tracked changes, comments or draft watermarks.
• It must be identical to the PDF that CEOS posts on the CEOS publications page.
• Name it CEOS_<Acronym>_<Short-Title>_v<Version>.pdf, with hyphens in place of spaces. Take the acronym from Annex B. For example, CEOS_SEO_DOI-Process-Paper_v1.0.pdf or CEOS_WGCV_Short-Title_vRev-2.0.pdf.
• Add supplementary files only if the Technical Coordinator agrees. Upload them after the PDF, so that the PDF stays first in the file list.

4.4 What to confirm when you submit

When you submit the draft (Section 6.1), your message must confirm that:

1. the document is its authors’ original work;
2. you have permission to use any material from other sources, such as figures, tables and quotations, and the document credits it; and
3. every named author has agreed to the final text and to its publication under their name.

Section 6.1 gives a message you can copy that includes all three. Keep any permissions you obtained for third-party material, in case you are asked for them.

5. Describe the record

Metadata is how people find and cite your document, so every record in the community follows the same standard. The table lists Zenodo’s fields in the order its upload form shows them. Review checks that each required field is present, correctly formatted and uses the values below. It never assesses what your document says.

Section 9 shows every field filled in for a worked example. Annex B lists the Zenodo resource types for content the community may accept in future.

5.1 Resource type

Choose Publication → Report. If you think another subtype fits better, ask the Technical Coordinator.

5.2 Title and version

Copy the title from the cover page exactly, including capitals and any “CEOS” prefix, but leave out the version number. Zenodo stores the version in its own field. All versions of a document are grouped under one concept DOI (Section 7.1), so the title should stay the same from version to version. If the document is widely known by a short name or acronym, you may add it as an additional title of type “Alternative title”.

Enter the version printed on the cover page, such as 1.0 or Rev 2.0, in the Version field. It changes with every new version.

5.3 Creators and contributors

• Enter every named author as a creator, in the order the document lists them. Put family and given names in their own fields.
• Give each person at least one affiliation: their employing agency or institution, chosen from the organizations Zenodo suggests as you type, if it appears there, rather than typed in. Record the CEOS entity in the keywords and the status block, not as an affiliation.
• Add an ORCID iD for every author who has one. Start typing each author’s name and, where Zenodo suggests them, choose them from the list rather than typing the details yourself. Choosing from the list can fill in the ORCID iD and affiliation for you.
• If the document is credited to a CEOS entity rather than to people, choose “Organization” as the creator type and enter the entity’s full name, for example “CEOS Working Group on Calibration and Validation”. Use the name from Annex B with “CEOS” in front.
• You may add editors, reviewers and others who are not authors as contributors, with the matching role.

5.4 Description

The description is your document’s abstract and the first thing most readers see. Name the authoring CEOS entity in the first sentence, and aim for 100 to 300 words. This pattern suits most documents:

This [document type] was developed by the [CEOS entity] to [purpose]. [Two or three sentences on its content, method or recommendations.] [One sentence on the Earth observation need it meets, and who it is for.]

Spell out each acronym the first time it appears. Leave the status out of the description. The status block records it.

5.5 Keywords

Every record uses the same CEOS keywords, so that the community can be searched and filtered consistently. Copy this block, fill in the two bracketed lines, and enter each line as a separate keyword:

CEOS
Committee on Earth Observation Satellites
Earth Observation

[your entity’s full name, from Annex B]

[your entity’s acronym, from Annex B] CEOS Pending

Keep CEOS Pending until status is conferred, then change it to CEOS Endorsed or CEOS Acknowledged (Section 6.3). A record that still carries CEOS Pending is never published.

Then add five to fifteen keywords about the content: the kind of document (strategy, best practice, guideline, specification), its Earth observation domain, the methods or products it covers, and its geographic scope if it has one. Where related records already use a term, use the same one.

5.6 Status and dates

Each record states the status behind its DOI, and when and where it was conferred. Three fields record this, and they must agree.

Before status is conferred, leave the publication date as Zenodo sets it, and do not add the “Accepted” date yet. Add an additional description of type “Notes” holding this pending status block:

CEOS status: Pending (endorsement or acknowledgement)
Expected at: [meeting, for example CEOS Plenary 2026]
CEOS entity: [full name (acronym)]

If the decision is deferred, update the expected meeting and leave the request open.

When status is conferred, complete all three fields (Section 6.3):

1. Publication date. Set it to the date status was conferred. Zenodo fills in the day you created the draft, which is usually earlier, so you must change it by hand.
2. Dates. Add one date of type “Accepted”, on the same day, with a description naming the status and the meeting, such as “Endorsed by CEOS Plenary 2026”. For a virtual endorsement, name the Secretariat decision instead, such as “Endorsed by CEOS Secretariat decision of YYYY-MM-DD”.
3. Status block. Replace the pending block with this one, one item per line:

CEOS status: [Endorsed or Acknowledged]
Conferred by: [meeting, for example CEOS Plenary 2026, City] or [virtual endorsement, Secretariat decision of YYYY-MM-DD]
Date conferred: YYYY-MM-DD
CEOS entity: [full name (acronym)]
DOI requested: [YYYY-MM-DD]
License note: [agency, license]
ceos.org copy: [address of the PDF]

Delete the “DOI requested” line for Endorsed documents; for Acknowledged documents, give the date your entity asked for a DOI. Delete the “License note” line unless an agency requires a license other than CC-BY-4.0.

5.7 Link to the ceos.org copy

CEOS keeps the authoritative copy of every document on the CEOS publications page, and the Zenodo record must link to that copy. Under “Related works”, enter the ceos.org address of the PDF. Choose the scheme “URL”, the relation “Is identical to”, and the resource type Publication → Report.

If you do not know the address yet, leave the link out. The Technical Coordinator adds it before publishing, and adds the DOI to the CEOS publications page afterwards.

5.8 License and funding

Use CC-BY-4.0, unless a contributing agency requires a different license. If one does, say so in your message to the curators and add the license note to the status block. CEOS records and their files are always public. They are never restricted or embargoed.

Record funding only when a specific grant or program paid for the work. Choose the funder from Zenodo’s list, and add the award number if there is one. General agency support does not need recording.

6. Submit, review and publish

On Zenodo, accepting a record publishes it and registers its DOI immediately. The Technical Coordinator therefore keeps your review request open until the review is finished and the Documentation Lead has confirmed the status. Status is usually conferred at a meeting of Principals, so the request may stay open for several weeks. This is normal. Your draft stays private and editable throughout, and Zenodo emails you whenever the Technical Coordinator comments.

6.1 Create the draft and submit it

1. Go to the CEOS community and click “New upload”. Starting there attaches the draft to the community.
2. Upload the PDF, reserve the DOI and fill in the metadata (Sections 4 and 5).
3. Click “Submit for review”. Zenodo asks you to confirm that curators may view and edit your draft, and that it will be published as soon as it is accepted. Confirm both.
4. In the message box for curators, paste this text and fill in the brackets:

Document: [title], version [version]
Status requested: [endorsement or acknowledgement], at [meeting]
DOI requested: [yes or no]
I confirm that:
1. the document is its authors' original work;
2. we have permission to use any material from other sources, such as figures, tables and quotations, and the document credits it; and
3. every named author has agreed to the final text and to its publication under their name.

Delete the “DOI requested” line for a document submitted for endorsement, which receives a DOI automatically. Section 9 shows a completed message.

6.2 Review

The Technical Coordinator checks your draft against this guide. They reply in the request, listing anything to fix and the section it falls under. Edit the draft and reply when you have finished. You do not need to submit it again. Curators sometimes correct small slips themselves, such as a misspelled keyword, and tell you when they do. When everything passes, the Technical Coordinator posts “Technical review complete; holding for status verification.”

Zenodo has no separate approval step. The whole review happens as a conversation in the request, which you can also find under “Requests” in your dashboard.

6.3 When status is conferred

1. Replace the PDF with the text that received status, under the status cover page, with the reserved DOI printed on it (Section 4.1).
2. Set the publication date and the “Accepted” date, and replace the pending status block with the final one (Section 5.6). Change the keyword CEOS Pending to CEOS Endorsed or CEOS Acknowledged.
3. Reply in the request to say that the draft is ready.

The Documentation Lead confirms the status against the CEOS status decision; you do not need to send any evidence. The Technical Coordinator then checks the dates and clicks “Accept and publish”. Zenodo registers the DOI, and the record goes public in the CEOS community.

If status is not conferred, the Technical Coordinator declines the request. You may delete the draft or keep it private. Either way, nothing is published and no DOI is registered.

6.4 After publication

1. Within a week, open the published record and work through the checks in Section 10.3.
2. Report anything wrong to the Technical Coordinator, with a screenshot if it helps. The Technical Coordinator raises platform problems with Zenodo support.

7. New versions and corrections

A change to a published document’s file always needs a new version, created with the “New version” button on the existing record. A change to its metadata alone is a correction, which the Technical Coordinator makes in place.

7.1 How Zenodo handles versions

Zenodo keeps every version of a document together and gives them two kinds of DOI:

• a version DOI for each version, which always leads to that version’s files, unchanged; and
• a concept DOI for the document as a whole, which always leads to the latest version.

Each version’s page links to all the others. The version DOI goes on that version’s cover page, because it identifies the exact text that received status. Cite the concept DOI when you mean “this document, whichever version is current”.

Always create a new version from the existing record, and never upload it as a separate record. That keeps the document’s whole history under one concept DOI. Zenodo’s help explains managing versions and DOI versioning in more detail.

7.2 Create a new version

A new version with changed text needs fresh status before it is published, so you begin it when the new text goes to Principals, as in Section 2. An editorial correction does not need fresh status. Because it changes the file, it is still published as a new version, and it keeps the original status, dates and status block. If you are not sure whether your change is editorial, ask the Technical Coordinator before you start.

1. Open the latest version’s record and click “New version”. You see this button only if you have edit access to the record. If you do not, ask the Technical Coordinator.
2. Click “Import files”, then replace the PDF with the new version of the document.
3. Reserve the new version’s DOI (Section 4.2).
4. Update the Version field and the ceos.org link, and check every other field for anything that has changed. Then:
   • for changed text, replace the status block with a pending block and delete the inherited “Accepted” date (Section 5.6);
   • for an editorial correction, keep the status block and dates as they are, and print the new DOI on the status cover page now.
5. Submit the draft to the CEOS community for review, and continue from Section 6.1, step 3. For an editorial correction, skip Section 6.3: the Technical Coordinator publishes once review is complete. If Zenodo offers to publish the new version immediately, do not publish it. Contact the Technical Coordinator instead.

Zenodo also lets an owner change a published record’s files without creating a new version. Do not use that option for CEOS records, because the published file is the text that holds status.

If an earlier edition of the document exists only outside Zenodo, link to it under “Related works” with the relation “Is new version of”.

7.3 Correct the metadata

Metadata can be corrected after publication without a new version or fresh status. The DOI stays the same, and Zenodo passes the corrected details on to DataCite, which registers the DOI. Typical corrections are:

• a misspelled name, or a typing error in the description;
• a missing or wrong affiliation, ORCID iD, keyword, related work or funding entry; and
• a broken link.

Email the Technical Coordinator with the record’s DOI and the change, and they will make it. Two things are never corrected, because they need a new version: the file, and the Version field. The status block, publication date and “Accepted” date are corrected only to match the CEOS status decision.

8. Documents that already have a DOI

A document that already has a DOI keeps it, and CEOS does not create a second one. What you do depends on who issued the DOI. Whichever applies, tell the Technical Coordinator about the existing DOI before you create anything.

8.1 The document is already on Zenodo

Do not upload it again. Zenodo accepts each DOI only once, and a second record would split the document’s downloads and citations between two records. Only the record’s owner can submit it. If you are not the owner, ask the owner to do it, or contact the Technical Coordinator.

1. Open the published record, click the cog icon to open the communities menu, and choose “Submit to community”.
2. Select the CEOS community, confirm that curators may view and edit the record, and write a message as in Section 6.1, step 4.
3. While the request is open, update the metadata to meet Section 5: the keywords, the publisher, the dates, the status block and the ceos.org link. Curators can edit it too, and may make some of these changes for you.
4. The file on the record must be the text that received status. Once the Documentation Lead has confirmed the status, the Technical Coordinator accepts the record into the community. Its existing DOI becomes its CEOS DOI, and its download and citation history carries over.

A file published before status was conferred does not carry the status cover page. It is accepted as it stands, with the status recorded in the metadata, and the cover page is added with the next version. Zenodo’s help explains submitting a published record to a community.

8.2 The DOI was issued by another publisher

1. Create the draft from the CEOS community page (Section 6.1).
2. At “Do you already have a DOI for this upload?”, answer “Yes” and enter the DOI. Zenodo checks it and does not create a new one.
3. Print the existing DOI on the status cover page.
4. Fill in the metadata and submit the draft for review as usual.

The DOI still leads to the original publisher’s page, which CEOS does not control. The Zenodo record adds the document to the CEOS collection.

This route is for a document that is the same work as the one already published. If its content differs beyond the cover page, talk to the Technical Coordinator before you create a draft.

8.3 Publishing elsewhere later

If a journal or an agency repository later publishes a document that has a CEOS DOI, give that publisher the CEOS DOI, so that the same work does not end up with two.

9. A worked example

This is the complete metadata for the CEOS DOI Process Paper as it would be entered after endorsement at CEOS Plenary 2026. Items in square brackets are filled in once they are known.

Description

This process paper was developed by the CEOS Systems Engineering Office to define how Digital Object Identifiers (DOIs) are assigned to CEOS documents through the CEOS community on Zenodo, with DataCite as the registration agency. It bases eligibility solely on a document’s status under the CEOS Governance and Processes paper: Endorsed documents receive a DOI automatically, and Acknowledged documents receive one if the submitting entity requests it. The paper sets out the roles of the submitter, the Documentation Lead and the Technical Coordinator, a workflow in which Zenodo preparation runs alongside review by Principals, and rules for versions, corrections and documents that already have a DOI. It is intended for CEOS Working Groups, Virtual Constellations and other entities preparing documents for publication.

Pending status block, before the Plenary

CEOS status: Pending (endorsement)
Expected at: CEOS Plenary 2026
CEOS entity: Systems Engineering Office (SEO)

Final status block, after endorsement

CEOS status: Endorsed
Conferred by: CEOS Plenary 2026, [City]
Date conferred: [YYYY-MM-DD]
CEOS entity: Systems Engineering Office (SEO)
ceos.org copy: [address of the PDF]

Message to the curators

Document: CEOS Digital Object Identifier (DOI) Process Paper, version 1.0
Status requested: endorsement, at CEOS Plenary 2026
I confirm that:
1. the document is its authors' original work;
2. we have permission to use any material from other sources, such as figures, tables and quotations, and the document credits it; and
3. every named author has agreed to the final text and to its publication under their name.

10. Checklists

Use these lists to check your own work. The Technical Coordinator reviews against the same points.

10.1 Before you click “Submit for review”

• Zenodo account confirmed, and CEOS community invitation accepted (3)
• Any existing DOI raised with the Technical Coordinator (8)
• Draft started from the CEOS community page (6.1)
• DOI reserved (4.2)
• One final PDF, named to the convention and marked as the default preview (4.3)
• Resource type is Publication → Report (5.1)
• Title matches the cover page, with no version number, and the Version field is filled in (5.2)
• Every author entered, each person with an affiliation, and ORCID iDs added where they exist (5.3)
• Description names the CEOS entity in its first sentence (5.4)
• CEOS keywords, entity name and acronym, CEOS Pending and content keywords all present (5.5)
• Publisher set to the CEOS name (5)
• Pending status block added (5.6)
• Link to the ceos.org copy added, if you know the address (5.7)
• CC-BY-4.0 selected, or the agency’s license requirement explained (5.8)
• Message includes the title, status and meeting, the three confirmations and, for acknowledgement, the DOI choice (4.4, 6.1)

10.2 When status is conferred

• PDF replaced with the text that received status, under the status cover page (4, 6.3)
• Reserved DOI printed on the status cover page (4.1)
• Publication date set to the date status was conferred (5.6)
• “Accepted” date added, naming the status and the meeting (5.6)
• Final status block in place, and CEOS Pending replaced with the status conferred (5.5, 5.6)
• Reply posted in the request to say the draft is ready (6.3)

10.3 Within a week of publication

• The DOI on the cover page leads to the record
• The record is listed in the CEOS community
• The metadata, status block and dates display as entered
• The PDF downloads and opens
• The ceos.org link works, and the CEOS publications page shows the DOI

11. Troubleshooting

Annex A. For the Technical Coordinator

This annex describes the curator’s side of the process: how the community is set up, and what to check before clicking “Accept and publish”, the step that registers a DOI.

A.1 Community settings

A.2 Review rubric

Reply in the review request with every check that fails, and cite its section. Fix small slips yourself only where the fix is unambiguous, and say so in the request. Never edit the document’s text or judge its content.

When every check passes, post “Technical review complete; holding for status verification.”

A.3 Before “Accept and publish”

• The Documentation Lead’s confirmation of status is recorded in the request
• The PDF carries the cover page for the confirmed status
• The DOI printed on the cover page matches the reserved DOI
• The publication date is the date status was conferred, not the day the draft was created
• The “Accepted” date, final status block and status keyword all agree with the confirmation, and no CEOS Pending keyword remains
• The “Is identical to” link to the ceos.org copy is present and resolves

A.4 After publication

1. Add the DOI to the document’s entry on the CEOS publications page.
2. Keep the email that requested each later metadata correction, as the record of what changed and why.

Annex B. Reference lists

B.1 CEOS entity names for keywords

Enter the full name and the acronym as two separate keywords. Names and acronyms follow the current list on the CEOS website. If your entity is not listed, ask the Technical Coordinator for its keyword form.

B.2 Relations under “Related works”

B.3 Resource types for future content

Note that the community currently takes only documents that hold a CEOS status. These mappings are kept for content it may accept later.

Annex C. Version history