Building a Research Workflow — Templates, Notes and Repeatability

Ad-hoc prompting fails in a specific way that is easy to miss while it is happening. Each answer looks fine on its own. The problem only shows up when you try to use two of them together.

Say you read the quarterly concall of a cement company in October and asked the model for “the main risks management flagged”. In January you read a second cement company and asked for “what management sounded worried about”. Both replies were reasonable. Neither is comparable to the other, because they answered subtly different questions with different structures and different levels of detail. You now have two summaries you cannot put side by side, which was the entire reason for reading two companies.

The second failure is recall. A month later you have a note that says “management guided cautiously on realisations”. Where did that come from? The transcript, or the model’s general knowledge of the sector? Without the source pinned to the claim, you cannot tell, and a claim you cannot trace is a claim you cannot act on.

The third is simple waste. You spent twenty minutes constructing a prompt that produced an excellent filing summary and then closed the tab. Next quarter you rebuild it from memory, slightly worse. Multiply that across a watchlist and a year, and the cost is enormous — not in rupees, but in the compounding you never got.

A working research workflow has exactly three parts. None of them is a piece of software you have to buy or build. All three are files you own.

The first is a template library — one fixed prompt per recurring task. A screening prompt. A filing-summary prompt. A concall-summary prompt. A thesis-draft prompt. Each one written once, saved, and reused verbatim so that every company you run it against comes back in the same shape. Same headings, same order, same fields. That sameness is what makes twelve summaries into a comparable set instead of twelve essays.

The second is a place to put source material. The model should be reasoning over the transcript you pasted, not over whatever it absorbed about the sector during training. Every template therefore has a slot: paste the document here, and answer only from it. This single design choice removes most of the failure modes the rest of this module is about.

The third is your notes file — the verified claims you have already checked, dated, with their sources attached. This is the asset that compounds. When you come back to the same company next quarter, you paste last quarter’s verified notes in alongside the new transcript and ask what changed. The model is now working with your history, not its own.

A template is a prompt you have stopped editing. That is the whole definition, and the discipline is harder than it sounds, because there is always a temptation to tweak it slightly for the company in front of you. Resist it. The moment you change a heading for one name, that name is no longer comparable with the other eleven.

Write one template per task, not one per company. Four templates cover most equity research work: a filing summary, a concall summary, a numbers-extraction pass, and a thesis draft that argues against itself. Each specifies the exact output structure, the exact fields, and what the model should do when the source does not contain an answer.

That last part deserves emphasis. Every template must give explicit permission to say “not stated in the source”. Without it, a model asked for six risk factors will produce six risk factors whether or not the transcript mentioned six, and the ones it invents will be phrased exactly like the ones it found. Permission to come back short is what makes a short answer possible.

Store the templates somewhere you can copy from in two seconds — a plain text file, a note, a snippet manager. If retrieving the template takes longer than rewriting it, you will rewrite it, and the workflow quietly stops existing.

A language model has two very different places its answers can come from. One is the text you put in front of it. The other is a compressed statistical impression of everything it read during training. The first is checkable. The second is not, and it is stale by definition, because training stopped at some point in the past.

Every template in your library should force the first. Paste the transcript, paste the filing pages, paste the press release. Then instruct it explicitly to answer only from that text. The phrase “using only the text between the markers” does more for output quality than any amount of clever prompt phrasing.

This has a practical consequence for how you organise files. You need the source material accessible in a form you can copy from — a folder of downloaded transcripts and filings, named consistently, one file per document per quarter. Not bookmarks to web pages you will have to re-navigate, and not a memory of where you saw it.

It also sets the size of your unit of work. One document, one prompt. A 300-page annual report does not go in whole; the segment note goes in, then the related-party note, then the auditor’s observations, each as its own pass. Smaller units mean the model’s attention stays on your text, and it means each answer is checkable against a specific set of pages.

You will hear the term retrieval-augmented generation, usually shortened to RAG. Stripped of the jargon it means one simple thing: before the model answers, go and fetch the relevant documents and put them into the prompt, so the answer is generated from those documents rather than from memory. That is it. Retrieve, then generate.

In a built system, the retrieval step is automatic. Your documents are indexed, and when you ask a question the system searches that index, pulls the three or four most relevant passages, and quietly inserts them above your question before sending it to the model. The reader sees a chat box. The machinery underneath is a search engine feeding a language model.

Here is the point that matters for you: the search step is the part doing the work, and you can do it yourself. A folder of your own past verified summaries, named sensibly, that you search with your operating system and copy from, gets you most of the benefit of a RAG system with none of the engineering. You are the retrieval layer. It is slower per query and it is entirely sufficient.

The second point is that grounding quality beats retrieval sophistication. A system that automatically fetches four mediocre passages is worse than you manually pasting the two paragraphs you know are the right ones. Before anyone builds anything, the honest question is whether the manual version has been running long enough to feel slow. Usually it has not.

A note without a date is nearly useless six months later, because you cannot tell whether it describes the company as it was or as it is. A note without a source is worse than useless, because you will trust it without being able to check it.

So every note in your file carries two extra lines. A date — when you wrote it, in a fixed format. And a “verified against” line naming the exact document and location the claim came from: “Q2 FY26 concall transcript, management opening remarks” or “annual report page 143, segment note”. Two seconds to write, and it converts a claim into evidence.

Never overwrite the previous quarter’s note. Append. The whole reason last quarter’s note is valuable is that it lets you see the change, and a file that only ever holds the latest state has thrown away the one thing you were accumulating. Keep them in sequence and let the file get long.

Mark unverified items explicitly rather than leaving them ambiguous. A line prefixed “UNVERIFIED — model claim, not yet checked” is safe to keep in the file. The same line without the prefix will be read as fact by you, in a hurry, next quarter. Ambiguity in a research file always resolves in the wrong direction.

There is a habit almost everyone develops and almost nobody questions: keeping one enormous ongoing conversation with the model and adding to it forever. It feels efficient. It degrades quality in a way that is hard to notice from the inside.

Two things go wrong. The context window — the amount of text a model can hold in view at once — fills up, and older material gets pushed out or attended to less closely. And the earlier content contaminates the later. Ask about a second company in a thread where you spent an hour discussing the first, and the framing, the assumptions and sometimes the actual figures from the first bleed into the answer about the second.

The fix is boring. One document, one thread. New transcript, new conversation. When you want to compare across companies, do not rely on the thread’s memory to hold both — paste your verified notes from the first company into a fresh thread alongside the second. Your notes file is the memory. The chat is not.

This is also why the workflow treats chats as disposable. If everything important has already been extracted, verified and written into your notes file, you can close any conversation at any time and lose nothing. That test — could I close this tab right now without losing anything? — is a good way to check whether your workflow is actually running.

The setup is genuinely small. Three folders and one document, built in an afternoon, and after that the marginal cost per company is a copy and a paste.

Do not try to write all four templates before you start. Write the one for the task you do most often, run it on four or five real documents, and let the failures tell you what the template is missing. A template edited against real output after five runs is better than one designed carefully in the abstract.

Expect the first month to feel slower than ad-hoc prompting, because it is. You are paying setup cost. The return arrives the second time you look at the same company, when last quarter’s verified notes turn a fresh read into a comparison — and that is a different and far more valuable exercise.