Day 2 — Writing a Proposal

Updated

September 27, 2026

[to be updated]

Day 2 is about writing: what goes into a research proposal, how citations work under the hood in LaTeX, and a short hands-on session in Overleaf. In the afternoon, each team works with its mentor to turn yesterday’s solution outline into research questions with hypotheses and a first experimental plan. I’ll keep using the illustrative health misinformation brief from Day 1.

Schedule

All sessions are at NUS Innovation 4.0.

Slot	Activity	Location
20 min	Writing tutorial: how to make a research proposal	Lecture hall
15 min	Writing tutorial: reading a BibTeX entry	Lecture hall
20 min	Writing exercise in Overleaf	Lecture hall
—	Break	—
2 hr	Research project: mentor consultation	Tutorial room

Deliverable: continue to refine the solution and idea.

Daily Recap

We start by revisiting the problem selection and solution outline from Day 1: the problem statement, the one or two research questions, and the rough idea of the approach. Today we turn that outline into the skeleton of a proposal, so by the end of the afternoon every part of the proposal has at least a placeholder.

Writing Tutorial

How to Make a Research Proposal

Recall that a research question (RQ) says what we want to find out to address the problem statement. A hypothesis says what we expect the answer to be, in a form that can be tested empirically. Strong RQs are specific, grounded in a gap from the literature, and answerable within the project’s constraints.

Note

This is only one way to form RQs and hypotheses. In other kinds of work, such as proving theoretical bounds, the process can be different. Work with your mentors or advisors to find the method that suits your kind of research.

	Weak	Strong
RQ	“How can AI detect misinformation?”	“Do token-attribution explanations remain faithful when health-misinformation classifiers are applied to code-mixed English–Singlish text?”
Why	Too broad, not answerable, no gap	Specific, tied to a documented gap, testable in 5 weeks

Each RQ is then paired with a testable hypothesis:

Example — RQ and hypothesis

RQ: Do token-attribution explanations remain faithful for code-mixed Singlish input?

Hypothesis: Explanation faithfulness (measured by attribution–accuracy agreement under token deletion) is significantly lower for code-mixed inputs than for monolingual English inputs, because the model attends disproportionately to English tokens.

What makes this testable: it names a metric, a comparison, and a directional prediction with a stated mechanism.

A good experimental plan in a proposal shows how each RQ will be answered and is honest about feasibility. In a short sprint, prefer plans that reuse existing datasets and models over plans that need new data collection or training from scratch.

Example — experimental plan sketch

Data: an existing English health-misinformation dataset + a small set of code-mixed examples (translated/adapted, or sourced from public Singlish corpora within PDPA limits).
Models: two off-the-shelf pre-trained classifiers with attribution methods (no training from scratch).
Measure: faithfulness via token-deletion agreement, compared across English vs. code-mixed inputs.
Expected outcome: a quantified faithfulness gap, plus qualitative examples of where attributions break down.
Limitations: small code-mixed sample; results indicative rather than definitive.
Budget: last but certainly not the least, would be to keep a rough estimate of the costs for this project (e.g., API costs, GPU hours, compute wall-clock etc.)

The proposal should contain at least these points:

Problem — the gap and why it matters (from Day 1, refined).
Literature / Introduction — what exists and what it leaves open (from the Day 1 reading and the Day 3 literature search).
Proposed direction — the RQs, hypotheses, and experimental plan.
Expected outcomes — what a meaningful result looks like, and the limitations.

The proposal is at most 3 pages, so every paragraph or diagram should add something to it. A rough page budget is half a page on problem and motivation, half to one page on literature and gap, half to one page on the proposed direction and plan, and half to one page on expected outcomes and constraints.

We collected more writing advice on this page. Check it if you need references or help.

Reading a BibTeX Entry

A proposal cites its sources, and in LaTeX the citations come from a .bib file. When you find a paper on Google Scholar, copy its citation from Cite → BibTeX and paste it into the .bib file of your Overleaf project:

Example — BibTeX from Google Scholar

@inproceedings{author2023misinfo,
  title     = {Explainable Detection of Health Misinformation in Short Text},
  author    = {Author, A. and Author, B.},
  booktitle = {Proceedings of EMNLP},
  year      = {2023}
}

Scholar often lists a published paper’s venue as arXiv preprint even after it appeared at a conference. The best practice is to look for the original source/venue (e.g., ICML) that the article is published at!

Each entry has three parts:

The entry type, after the @. It says what kind of work this is: @inproceedings for a conference paper, @article for a journal paper, @misc for anything else, which is where arXiv preprints often end up.
The citation key, the first thing inside the braces (author2023misinfo above). It is the name used to cite the paper in the document, and it only has to be unique within the .bib file.
The fields, one name = {value} per line: title, author (names joined with and), booktitle for a conference or journal for a journal, year, and optionally pages and a url or doi.

A .bib file is a small database. It does nothing on its own; the LaTeX document cites from it with \cite{author2023misinfo}, and only the cited entries appear in the reference list. The bibliography style set in the document decides how each entry renders (author-year or numbered, abbreviated names or full ones), so nothing in the .bib file needs to be formatted by hand.

The entry type and venue fields are where exports most often go wrong. Google Scholar and arXiv often export an @misc or arXiv entry for a paper that later appeared at a conference. If the paper was published, cite the published venue: it is the peer-reviewed version, and it tells the reader where the work was checked.

Writing Exercise

For the exercise, each person clones the NeurIPS paper template into Overleaf. The coordinators share the template link on the day. Open the project, check that it compiles, and find the .bib file (create one called references.bib if the template has none).

Exercise 1 — clean up a bad BibTeX entry. Below is the kind of entry you get when you export “Attention Is All You Need” from its arXiv page. The paper was published at NeurIPS 2017 [1], so the entry should say so.

@misc{vaswani2017attention,
  title         = {Attention Is All You Need},
  author        = {Ashish Vaswani and Noam Shazeer and Niki Parmar and Jakob Uszkoreit
                   and Llion Jones and Aidan N. Gomez and Lukasz Kaiser and Illia Polosukhin},
  year          = {2017},
  eprint        = {1706.03762},
  archivePrefix = {arXiv},
  primaryClass  = {cs.CL},
  url           = {https://arxiv.org/abs/1706.03762},
  abstract      = {The dominant sequence transduction models are based on complex
                   recurrent or convolutional neural networks that include an encoder
                   and a decoder. ...}
}

The cleaned entry:

@inproceedings{vaswani2017attention,
  title     = {Attention Is All You Need},
  author    = {Vaswani, Ashish and Shazeer, Noam and Parmar, Niki and Uszkoreit, Jakob
               and Jones, Llion and Gomez, Aidan N and Kaiser, {\L}ukasz and Polosukhin, Illia},
  booktitle = {Advances in Neural Information Processing Systems},
  volume    = {30},
  year      = {2017}
}

What changed:

The entry type went from @misc to @inproceedings, because the paper is a conference paper, and the new booktitle and volume fields name the venue.
eprint, archivePrefix and primaryClass were removed. They point to the arXiv preprint, and once we cite the published version they only add clutter (some styles print them as an extra arXiv line).
url was removed because it pointed to the preprint rather than the published paper.
abstract was removed. The style never prints it, and it makes the .bib file long and hard to read.
The key stayed the same, so any \cite{vaswani2017attention} already in the document still works.

Exercise 2 — change the citation in the template. Add the cleaned entry to the project’s .bib file. Find the example citation in the template and replace it with \cite{vaswani2017attention}. If the template’s reference list is typed out by hand, replace it with a \bibliography{references} line and a bibliography style. Recompile, then check that the reference list shows the paper with its NeurIPS venue and no arXiv line.

Transformers rely entirely on attention \cite{vaswani2017attention}.

Exercise 3 — fix a broken maths equation. Paste the source below into the template and compile it. It has three mistakes: \top used outside maths mode, \sqrt d_k without braces, and a \right with no closing delimiter.

We compute attention as
\begin{equation}
  \mathrm{Attention}(Q, K, V) = \mathrm{softmax}\left(\frac{QK^\top}{\sqrt d_k}\right V
\end{equation}
where K^\top is the transpose of the key matrix.

The fixed source:

We compute attention as
\begin{equation}
  \mathrm{Attention}(Q, K, V) = \mathrm{softmax}\left(\frac{QK^\top}{\sqrt{d_k}}\right)V
\end{equation}
where $K^\top$ is the transpose of the key matrix.

It renders as:

\[ \mathrm{Attention}(Q, K, V) = \mathrm{softmax}\left(\frac{QK^\top}{\sqrt{d_k}}\right)V \]

Two of the mistakes stop compilation: \top and ^ outside maths mode give a “Missing $ inserted” error, and \right without a delimiter gives a “Missing delimiter” error. The third one compiles without complaint: \sqrt d_k takes the square root of d alone and leaves _k outside the root, so always compare the rendered equation against what you meant.

Research Project: Refining the Idea

In the two-hour session with your mentor, the team turns its Day 1 outline into research questions with hypotheses and a skeleton experimental plan. The team also sets up its own Overleaf project with its own .bib file, so there is a place for the citations collected from here on.

You Do — Formulate your RQs

As a team, draft 1–3 research questions for your problem. For each, write a testable hypothesis that names what you’d measure and what you expect. Then poke holes in each other’s formulations: is it specific? grounded in a gap? answerable in the time you have?

You Do — Outline the proposal

Sketch a one-page experimental plan for your main RQ (data, method, measure, expected outcome, limitations), then arrange your material into the four-part arc above. Keep it skeletal for now. The full prose is written on Day 4.

Checkpoint Deliverable: Day 2

At the end of Day 2, the team should have a refined idea: research questions with hypotheses and a skeleton experimental plan, written in an Overleaf project that compiles with at least one correctly formatted citation.

References

[1]

A. Vaswani et al., “Attention is all you need,” in Advances in neural information processing systems, 2017.