Podcast research in Jan: choose the file scope before adding your notes

[LMSlay]

For anyone using Jan to compare podcast research notes, there are two separate decisions before asking the model a question: which conversations should receive the material, and which model/provider may receive it.

Jan’s file-upload documentation distinguishes a message attachment from Project files shared as context across that Project’s conversations. It also distinguishes local-model processing from cloud-provider use, where files are sent through the provider’s API. “I’m using the Jan desktop app” is therefore not, by itself, a reason to assume the selected model keeps a file on the device.

A manual preparation checklist:

1. For a one-episode question, consider a message attachment rather than adding the episode to a reusable Project. If you want a Project-wide source set, choose that scope deliberately.
2. Check the selected model/provider and whether you are allowed to share the material there. Do not put private interviews or restricted transcripts into a cloud workflow merely because a local model is also available.
3. Keep a small Markdown note with the episode URL, available timestamp or passage locator, exact excerpt, your interpretation, and a separate “not checked yet” field. Leave missing timing or speaker information unknown; do not ask the model to invent it.
4. Ask the model to keep source passages separate from inferences, then verify important quotations against the episode. Moving a note into shared context does not verify the claim inside it.

I maintain TubeText. Our podcast research-notes guide includes a blank claim/evidence/verification worksheet; it can be used with a publisher-provided transcript without buying a tool. The guide also mentions our paid Apify option, which is not required for this checklist.

This is an AI-assisted, manually prepared reading workflow—not a Jan integration, a tested end-to-end example, or a claim that Jan produces these fields automatically.