Author Contribution Statement: Check Roles Before Submission

An author contribution statement names who did which work on a paper. Start with work each person has confirmed, then use the format the journal asks for. A list of plausible roles is not enough: each claim needs a person who agrees it fits their work.

This guide checks a fictional team's draft against its work record. One unsupported role is removed; another stays open for review. The example shows how to prepare a statement without guessing who belongs on the author list.

What the statement records

A statement can describe study design, data work, coding, writing and other tasks. It tells readers more than the author list alone. ICMJE's guidance separates these descriptions from the question of who qualifies as an author.

If the journal uses CRediT, choose roles from its shared list. The official NISO descriptors define fourteen roles. A person may hold more than one, and several people may share a role. There is no need to fill all fourteen slots.

Keep the basic claim clear: a name, the work done, and a fitting description of that work. Do not assign tasks from author order, job titles or seniority. A lab head may have done several tasks, but the title alone proves none of them.

Follow the journal's format

Check the submission instructions

Read the current instructions for the journal and article type. Find whether it requests role names, a prose paragraph, a form in its portal, or more than one of these. Note the required location and any separate approval fields.

Policies differ. Elsevier's statement guide shows a structured role format. AAS Journals currently permits an optional free-form section. The AAS rule does not mean another journal treats the statement as optional.

Save the rules with the draft so the team can check the work and the format. If the portal uses initials, ensure each set of initials maps to one person. If names overlap, use the journal's way to tell them apart.

Confirm work before choosing labels

Write what each person did in plain language first. Ask them to check the record. Then compare that work with the role definitions. NISO's implementation guidance supports discussing roles through the project and giving people a chance to review assigned roles.

Keep writing the first draft distinct from review of its ideas. Separate writing code from running an existing tool. A role should fit the work, not make it sound grander. If the record is unclear, ask the person. Do not stretch a role to fit.

A worked check of confirmed roles

Suppose a fictional team has three named people: Asha, Ben and Cara. Each has checked the plain-language work record below. The team has a draft role list. It has not signed off on the final text or met all journal checks.

Use these four entries to compare recorded work with draft claims before preparing a statement for team review.

Table 1: These are fictional confirmed records, not actual author declarations or a completed approval process.

Remove the unsupported assignment

The draft gives Asha Formal analysis, but the record only supports study aims, method design and first-draft writing. Remove the analysis claim from this draft unless further confirmed work supports it. Do not transfer it to another person merely to keep the role in the list.

Ben's use of a software package does not alone show that Ben developed software. NISO's role definition concerns code development and related programming work. Ask whether Ben wrote or tested relevant code. Until that work is confirmed, leave Software out of the example draft.

This is the same source check used in a careful paper analysis: keep what a source states apart from what a reader has guessed. Here, the work record supports some roles while leaving others open.

Prepare a bounded draft

A corrected example for review reads:

Asha: Conceptualization, Methodology, Writing – original draft. Ben: Data curation, Formal analysis. Cara: Writing – review & editing.

This draft uses only the work supplied in the example. It does not say that all authors approved the final manuscript, because no record of that step has been supplied. Add such claims only after the real team has met and confirmed those rules.

If a journal requests prose instead, describe the same work in plain sentences. Asha set the aims, designed the method and wrote the first draft. Ben managed the data and performed the analysis. Cara critically reviewed and revised the manuscript. A change in format should not change who gets credit for each task.

Keep approval and authorship separate

Review the wording with people

Each person should inspect the claims about their work and the proposed labels. Wiley's guidance expects authors to discuss and agree to their recorded roles. Note which draft they checked; signing off on an old draft does not mean they accept new words.

Shared work need not be forced onto a single name. Record each person's part. If the journal asks for lead, equal or supporting labels, agree to those claims too. Do not guess shares of work or rank effort from a brief work log.

Apply the separate authorship policy

CRediT does not decide who belongs on the author list. People must check who meets the journal's rules for authors. Where ICMJE rules apply, all its criteria must be met; one recorded role does not replace that full check.

Disputes about who belongs on the list or the order of names need team review. Follow the journal and the team's home institution rules if they cannot agree. The ICMJE responsibility guidance places these decisions with people and institutions, not an automated draft tool.

Compare the records in Atlas

1. Add the draft statement, person-confirmed work record, current journal instructions and relevant role definitions to one project. Use records the team permits you to share. Keep pending tasks and unconfirmed notes marked as such.
2. In Ask a question, use @ to select those sources. Ask: “Compare each draft role with the named person's confirmed work. Cite the supporting record and role definition. Mark unsupported or unclear claims. Do not infer work or authorship eligibility.”
3. Open each citation and read its context. Check the person, task, version and confirmation status. A plan saying someone will study data does not prove they did so.
4. Remove Asha's unsupported analysis role from the example and hold Ben's Software role for review. A source comparison workflow helps keep the work record, role definition and draft claim distinct.
5. Choose New → Note, save the alignment and open questions, then wait for Saved. Send the proposed wording through the team's human review process. Atlas cannot confirm work for someone or sign off on the text.

The image shows how source text beside a cited answer helps you inspect support. Its visible paper concerns AI research and is unrelated to this fictional team. It does not show an executed role check or author approval.

Read the supporting record before accepting a role, and retain a gap when confirmation is absent. Unchanged Atlas capture; visible paper: The AI Scientist-v2, by Yutaro Yamada and colleagues, CC BY 4.0.

Prepare the team review

Take the draft and alignment note back to the named people. Resolve unclear work, check spellings and role labels, and confirm the journal's required format. Recheck any changes made after review instead of treating earlier agreement as blanket permission.

Keep source reading apart from choices about credit. A literature review process may help organize source reading, but it cannot prove who did a task. The publisher's accuracy requirement still rests on the team's actual work and agreement.

Before sending the paper, the lead contact should check both the text and the rules for who can be an author. Keep open questions until the right person answers them. A concise statement is useful only when its names and claims are accurate.