Research often breaks down between a good question and a finished output: roles stay vague, evidence loses provenance, decisions disappear after meetings, and quality checks happen too late. This guide gives trainees a lightweight operating system for preventing those failures.
The operating loop
| 1. Charter | 2. Map | 3. Execute | 4. Control | 5. Close |
|---|---|---|---|---|
| Define the question, output, scope, roles, and approvals. | Map evidence, stakeholders, methods, dependencies, and risks. | Move bounded work through named owners and reviewable deliverables. | Track decisions, versions, exclusions, deviations, and quality checks. | Translate work into a reproducible output, contribution record, and next decision. |
Designed for trainees contributing to:
- literature reviews, evidence syntheses, educational audits, and survey projects
- retrospective or prospective research under an approved protocol
- data abstraction, quality control, figures, presentations, and manuscripts
- community-informed, qualitative, clinical, health-services, or implementation research.
This guide supports project operations. It does not determine scientific validity, regulatory status, authorship, statistical methods, clinical care, or data permissions. Follow the principal investigator, institutional policies, IRB or ethics requirements, data-use agreements, protocol, and applicable law.
1. Create a one-page project charter
Do not begin with a task list. Begin with a shared definition of the work. The charter should be brief enough to revisit and specific enough to expose disagreement.
| Charter field | Question it must answer |
|---|---|
| Research question | What precise uncertainty are we trying to reduce? What population, setting, exposure or intervention, comparator, and outcome matter when applicable? |
| Decision or use | Who may use the answer, and what could it change? |
| Primary output | Protocol, dataset, abstraction table, analysis, figure, abstract, presentation, manuscript, or another defined product? |
| Scope | What is included, excluded, deferred, or still unresolved? |
| Method and standard | What approved protocol, rubric, codebook, analysis plan, reporting guideline, or institutional procedure governs the work? |
| People and roles | Who decides, executes, reviews, approves, advises, and must be informed? |
| Milestones | What are the reviewable deliverables, dependencies, and decision dates? |
| Ethics and data | What approvals, consent rules, access controls, confidentiality requirements, and retention rules apply? |
| Definition of done | What evidence will show that the deliverable is complete and ready for the next stage? |
The charter coordinates the team around the approved work. It must not quietly expand eligibility, outcomes, data access, methods, or recruitment beyond the protocol and institutional approvals.
Charter test
- Could a new collaborator understand what the team is producing and what remains undecided?
- Can each person identify their next reviewable deliverable and reviewer?
- Would a scope change be visible before the work proceeds?
2. Build an evidence system, not a reading pile
Every claim should remain connected to its source, study design, context, and limits. The evidence table should make duplication, disagreement, and missing perspectives easier to see.
| Field | Record |
|---|---|
| Citation and stable identifier | Full citation plus DOI, PMID, registry ID, URL, or institutional locator when available. |
| Question and design | What the study asked and whether it is experimental, observational, qualitative, evidence synthesis, conceptual, commentary, or other. |
| Population and setting | Who or what was studied, where, when, and under what eligibility criteria. |
| Exposure, intervention, or phenomenon | What was measured, delivered, experienced, or compared. |
| Outcome and finding | The authors' reported result, separated from your interpretation. |
| Limitations and applicability | Bias, missingness, uncertainty, implementation conditions, and boundaries on generalization. |
| Project use | Why the source matters: background, method, measure, comparison, gap, contradiction, or discussion. |
| Disposition | Include, exclude, hold, replace, or seek full text - with a reason and reviewer. |
Evidence discipline
- Preserve article-level provenance. Do not blend several papers into one unsupported summary.
- Flag shared trials, cohorts, datasets, and overlapping publications so they are not counted as independent evidence.
- Distinguish association from causation and authors' findings from team interpretation.
- For culturally responsive work, name the actual adaptation: language, setting, community participation, personnel, family, food, faith, economics, access, or structural barrier.
Document why a source, participant, organization, variable, or record was excluded. A silent exclusion cannot be audited, reproduced, or defended later.
3. Translate the protocol into executable work
A protocol describes the approved scientific plan. The operating layer converts that plan into roles, fields, definitions, review rules, and handoffs without changing it.
| Operating element | Minimum specification | Control question |
|---|---|---|
| Unit of work | The article, record, participant, image, institution, variable, interview, or other item being processed. | What exactly moves through the workflow? |
| Eligibility | Operational inclusion and exclusion rules with examples and an escalation path. | Would two trained reviewers make the same call? |
| Data dictionary or codebook | Field name, definition, allowed values, source, missing-value rule, and notes. | Can another person interpret every field? |
| Rubric | Observable anchors for each score or classification, including borderline cases. | What distinguishes adjacent ratings? |
| Review model | Single review, dual independent review, adjudication, or another approved model. | Who checks what, and how are disagreements resolved? |
| Handoff | Owner, reviewer, file or system location, due date, acceptance test, and next state. | What must be true before the item moves? |
| Deviation path | How unexpected cases, protocol questions, and possible errors are paused, logged, and escalated. | Who has authority to decide? |
Run a small, representative sample through the full workflow. Compare interpretations, revise instructions through the approved process, freeze the next version, and only then expand. A pilot is a test of the operating system, not permission to change the study informally.
A reporting guideline helps you describe the work
Select the appropriate guideline early enough to reveal missing documentation. EQUATOR emphasizes that reporting guidelines support transparent reporting; they do not replace study design decisions or quality appraisal.
4. Make ownership and contribution visible
Titles alone rarely explain how work moves. Track responsibility for each deliverable and separately track the contributions people actually make.
| Role | Operational responsibility |
|---|---|
| Decision owner | Makes or escalates the defined decision; confirms scope and acceptance criteria. |
| Work owner | Produces the deliverable and communicates risks before the due date. |
| Reviewer | Checks against the protocol, rubric, codebook, analytic plan, or other agreed standard. |
| Approver | Authorizes the work to move to the next state when formal approval is required. |
| Contributor | Provides a defined input, technical function, relationship, interpretation, or supporting deliverable. |
| Informed stakeholder | Needs the decision or status but does not own the work. |
Deliverable ownership table
| Deliverable | Owner | Reviewer | Due / state | Acceptance test |
Discuss credit before submission
- Use the team's institutional and journal authorship policies; do not promise authorship casually.
- Revisit expectations when scope, contribution, or personnel changes.
- Use CRediT roles to describe contributions such as conceptualization, data curation, methodology, analysis, visualization, supervision, and writing.
CRediT makes contributions visible but does not determine who qualifies as an author. Authorship also carries accountability and must follow the applicable policy. Confirm assigned roles with contributors.
5. Run the project from a controlled workboard
A useful workboard shows state, ownership, evidence, and blockers. It should not become a second undocumented protocol or a private list that the team cannot interpret.
| Field | Why it matters |
|---|---|
| Task or record ID | Creates a stable reference across meetings, files, and review comments. |
| Deliverable and acceptance test | Defines the output and what must be true before it is complete. |
| Owner and reviewer | Prevents invisible labor and ambiguous handoffs. |
| State | Use a small controlled set: Not started, Active, In review, Blocked, Waiting, Complete. |
| Due date and dependency | Separates real deadlines from preferences and exposes sequence risk. |
| Source or file location | Points to the canonical artifact instead of spawning copies. |
| Blocker and next action | Names what is preventing movement, who can resolve it, and when it will be revisited. |
| Decision or change reference | Links the work to the decision log, version, protocol clarification, or approved deviation. |
State-transition rules
| Move | Required evidence |
|---|---|
| Active -> In review | The deliverable exists in the canonical location; the acceptance test is self-checked; known limitations are stated. |
| In review -> Complete | The named reviewer has checked it; required changes are resolved or documented; approval is recorded when applicable. |
| Any state -> Blocked | The blocker, effect, decision owner, next action, and review date are visible. |
| Complete -> Reopened | New evidence, discovered error, changed scope, or failed acceptance test is logged with a reason. |
When outreach, abstraction, coding, or review has been completed, preserve the historical record. Correct through a visible change or new version rather than silently overwriting what happened.
6. Make meetings produce decisions
A research meeting should reduce uncertainty and move work. Circulate enough context for the team to decide, then capture the outcome where the work lives.
Before the meeting
| Item | Prepare |
|---|---|
| Decision | State the choice, decision owner, deadline, and consequence of waiting. |
| Evidence | Link the relevant protocol section, table, analysis, example, or prior decision. |
| Recommendation | Offer a proposed direction and the strongest credible alternative. |
| Risks | Name the scientific, ethical, operational, timeline, and stakeholder risks. |
| Status | Use Situation, Meaning, Action, Need for concise updates that do not require discussion. |
After the meeting
| Decision | Rationale / evidence | Owner | Due | Reopen trigger |
Decision note
- What was decided, deferred, rejected, or escalated?
- What evidence and assumptions shaped the decision?
- What changed in the protocol, codebook, rubric, analysis, timeline, or workboard?
- Who owns the next output, who reviews it, and when is it due?
Name the decision and ask for confirmation. When power differences matter, provide a channel for questions or dissent that does not require challenging a senior person publicly.
7. Control quality before the final draft
Quality control should be designed into each handoff. A final review cannot reconstruct missing provenance or reliably detect every silent change.
| Control | Apply it to | Evidence retained |
|---|---|---|
| Training and calibration | Eligibility, abstraction, scoring, coding, interviewing, or other interpretive work | Training examples, questions, calibration results, and approved clarifications. |
| Independent review | High-risk classifications, key outcomes, or protocol-defined dual-review work | Reviewer records, disagreements, and adjudication decisions. |
| Range and logic checks | Structured data and calculated fields | Rules, exceptions, queries, resolutions, and rerun results. |
| Source verification | Claims, numbers, quotations, tables, and figures | Direct source locator and verifier. |
| Version control | Protocols, codebooks, datasets, code, figures, and manuscripts | Version, date, owner, change summary, and approval when needed. |
| Reproducibility check | Analysis or transformation workflows | Inputs, code or steps, environment or software details, and expected output. |
| Privacy and access check | Data, outreach lists, recordings, transcripts, and shared files | Approved location, permissions, retention rule, and incident path. |
Change log
| Date / version | What changed | Why | Approved by | Affected work / action |
Do not patch a table or figure without identifying whether the source data, definition, analysis, transcription, or display is wrong. Correct the causal layer, rerun dependent work, and document the change.
8. Build the output while the work is happening
Do not wait for a blank manuscript to discover that methods, decisions, limitations, and contributor records are missing. Build a living output map from the beginning.
| Output element | Maintain during the project |
|---|---|
| Introduction | Problem, decision relevance, prior evidence, contradiction or gap, and the precise study objective. |
| Methods | Protocol and approvals, design, setting, eligibility, variables, instruments, procedures, analysis, missingness, quality controls, and deviations. |
| Results | Planned tables and figures, denominator logic, participant or record flow, primary findings, uncertainty, and sensitivity analyses when applicable. |
| Discussion | What the findings establish, what they do not establish, relation to prior evidence, implementation implications, limitations, and next questions. |
| Contributions | Current contribution record, acknowledgements, data or code availability statements, conflicts, funding, and required disclosures. |
| Submission | Target audience and journal, author instructions, reporting checklist, word and figure limits, required files, and approval sequence. |
Figure and table brief
| Decision | Question |
|---|---|
| Purpose | What single claim, pattern, comparison, flow, or distribution should the reader understand? |
| Source | Which version of the data and analysis produced it? |
| Definition | What are the denominator, units, categories, missing values, and exclusions? |
| Review | Who verifies the numbers, labels, accessibility, privacy, and consistency with the text? |
| Boundary | What should the reader not infer from this display? |
Use the relevant EQUATOR guideline during protocol and output planning to reveal documentation needs. Confirm the journal's current requirements before submission. A completed checklist does not prove that a study was well designed or executed.
One-page research control sheet
Project / question: ___________________________________________________________________________________
Primary output and use: ______________________________________________________________________________
| Scope and governing documents | People and decision rights |
|---|---|
| Protocol / IRB or ethics status / codebook / reporting guideline / data-use rules / inclusions / exclusions | PI or decision owner / work owners / reviewers / approvers / advisors / stakeholders |
| Current evidence and uncertainty | Current deliverables and dependencies |
| Strongest evidence / contradiction / gap / assumption / unresolved scientific or operational question | Output / owner / reviewer / state / due date / blocker / acceptance test |
| Decision needed | Quality, ethics, and data checks |
| Choice / owner / deadline / recommendation / alternative / cost of waiting / reopen trigger | Approval / privacy / access / calibration / verification / version / deviation / incident path |
Next update
Situation: _______________________________________ Meaning: __________________________________________
Action: __________________________________________ Need and deadline: __________________________________
What could make the team believe the project is moving while the scientific, ethical, or operational foundation is quietly weakening?
Standards and scope
Use this operating guide within the approved protocol, your assigned role, and current institutional requirements. It supports reliable trainee contribution but does not replace project-specific research, ethics, data-governance, authorship, or reporting policy.
Authoritative resources to consult
| Resource | Use |
|---|---|
| EQUATOR Network reporting-guideline library | Find reporting guidance appropriate to the study design. EQUATOR states that reporting guidelines support clear reporting and are not design or quality-appraisal tools. |
| ICMJE Recommendations: roles of authors and contributors | Check widely used biomedical-journal guidance on authorship credit and accountability, then follow the target journal and institution. |
| CRediT Contributor Role Taxonomy | Describe specific contributions through 14 standardized roles. CRediT explicitly does not determine authorship. |
| NIH Rigor and Reproducibility resources | Review current NIH policy and resources on rigor, transparency, and reproducibility when relevant. |
| Local protocol, IRB or ethics office, data-use agreement, and institutional policy | These govern the actual project and take precedence over this guide. |
Links verified September 16, 2026
equator-network.org/reporting-guidelines
icmje.org/recommendations - authors and contributors
grants.nih.gov - rigor and reproducibility
Before using the system
- Confirm the approved scope, your role, data location, access permissions, and escalation path.
- Use only systems and data that you are authorized to access; never move sensitive data into a personal tool.
- Ask when uncertain. A hidden assumption is more dangerous than a visible question.
Reliable contribution means the team can understand what you did, trace it to its source, review it against an agreed standard, reproduce the critical steps where appropriate, credit the people involved, and see when or why the work changed.
Prefer to work offline?
Keep a printable copy.
The web page is the primary guide. The PDF contains the same core material in a format you can save, print, annotate, or carry into a conversation.
Download the printable guide