1. Executive summary

This section, expected to be no more than two pages in length, needs to clearly address the following questions.

The “why\(\to\)how\(\to\)what” of your project:

• What is the project about?
  • problem you are addressing;
  • why it is relevant / important;
  • why is it challenging – either for society or within your discipline (answer what is most appropriate for your project, at best, answer both!);
• Who are the stakeholders? Participants?
  • who does the project affect;
  • who is a critical participant;
  • who can benefit in the end;
• What is the project topic, area, major, methods?
  • not everyone has any idea about the tools you are using. It is extremely important to set the stage for the audience. For example, if you are doing statistical modeling of social networks, you need to define what is a social network, and what is a statistical model, and why does anyone connect these two concepts (what’s the idea behind the area within which your problem is embedded). As another example, if you are studying an effect of A on B (or their relationship) via an observational study, you need to explain what this relationship means in practice in society, and what it means in technical terms within a discipline.
• What are the key findings?
  • did you discover any new patterns?
  • do you have a proposal for society (or your neigborhood or your micro-society)?
  • do you have a policy recommendation?
  • etc.
• What issue related to social justice or equity was solved or addressed? How?
  • The most exciting message! :)
• What issue related to social justice or equity was not solved or addressed? Why?
  • Identify any roadblocks or issues. This is equally as important as the above!

2. Technical details

This section does not have a length restriction. You should feel free to write as much details as you find necessary to explain the technical backbone of your project. Some example things to consider:

• Project timeline. When did you begin? when did you finish? what are some major time points and events that shaped your project - say, you got data, or you made a discovery, or you had to change course…
• Context. Within your field of research (or within the area of this project), how does one typically approach the problem, from what you’ve seen? Did you follow the usual? Did you use any out-of-the-box software, tools, sites, etc.?
• Data. Did you collect data? What was the process like? Did you design a survey? How did you do so? Etc.
• Hands-on: analyses. What kinds of (non)technical analyses did you do?
• Conclusions. Write all conclusions clearly. And assumptions. These are meant to be technical conclusions that translate directly to the high-level conclusions you wrote in the executive summary.

3. Bibliography

You must cite any and all resources used throughout your project. You should cite each reference in the text above where appropriate and list the full bibliographic entry here in this section. Each Fellow is expected to follow the style guidelines for his/her/their discipline. If you are not sure how to do this, please reach out to a (SoReMo) faculty member for help!

4. Appendix

Additional analyses, figures, tables, code, any other parts of the ‘report’ you want to preserve and be able to point to, but do not fit in the main project storyline narrative.

1. Know Your Dual Audience

SoReMo reports typically serve two audiences:

• Academic readers (for publication in the SoReMo Journal)
  
• Community readers (stakeholders, residents, organizers, policymakers)

Your report should be structured so both groups can understand and use your work.

General rule:
- Full technical detail → main body for journal publication
- Simplified explanations → summaries or appendices for community versions

2. Start With a Clear, Relatable Problem Statement

Open with a concrete scenario or example that helps readers understand why your project matters.

Good openings: - Describe a real‑world situation
- Use a short narrative or everyday analogy
- Connect the issue to lived experience

Avoid: - Starting with abstract theory
- Leading with dense technical language

3. Explain Key Concepts in Plain Language

Every project has terms that may be unfamiliar to non‑experts. Define them early and simply.

Tips: - Use analogies
- Provide short definitions
- Add a glossary if needed

Your goal is to make the report readable without sacrificing accuracy.

4. Use Case Studies or Examples When Possible

Concrete examples help readers understand the stakes and context of your work.

Examples can include: - A neighborhood
- A dataset
- A historical event
- A policy decision
- A specific user group

Case studies make abstract issues more tangible.

5. Keep Technical Sections Rigorous but Organized

Your methodology should be transparent and replicable. For the SoReMo Journal, include:

• Data sources
  
• Analytical methods
  
• Assumptions and limitations
  
• System or model design
  
• Visuals or diagrams if helpful

For community‑facing versions, consider: - Moving technical detail to an appendix
- Providing a short “How this works (in simple terms)” summary

6. Make Your Findings Actionable

Every SoReMo project should help someone make a better decision.

Include: - Clear takeaways
- Practical recommendations
- Tools, templates, or questions stakeholders can use
- Policy or design implications

Avoid vague or purely descriptive conclusions.

7. Use Visuals Thoughtfully

Visuals help readers understand complex information quickly.

Useful visuals include: - Maps
- Diagrams
- Flowcharts
- Before/after comparisons
- Simple charts

Make sure visuals are: - Labeled
- Interpretable
- Accessible (color‑blind friendly, readable text)

8. Be Transparent About Limitations

Every project has constraints. A strong report acknowledges them clearly.

Examples: - Data gaps
- Uncertainty
- Assumptions
- Scope boundaries

This builds trust and strengthens your conclusions.

9. Maintain an Ethical Lens

SoReMo emphasizes socially responsible modeling. Your report should reflect:

• Awareness of equity impacts
  
• Consideration of who benefits and who is burdened
  
• Transparency about risks
  
• Respect for affected communities

Ethics should appear throughout the report, not only in one section.

10. End With a Clear, Grounded Conclusion

Your conclusion should:

• Summarize the main insights
  
• Reconnect to the original problem
  
• Highlight what your work enables next
  
• Avoid overstating certainty

A good conclusion leaves readers with clarity, not confusion.

11. Optional but Encouraged: Create a Community‑Friendly Version

If your project affects real people, consider preparing:

• A 1–2 page summary
  
• A handout
  
• A slide deck
  
• A simplified appendix
  
• A “community explainer”

This helps your work reach beyond the academic setting.