Review: category-session-sop notebook

[lalithaar]

@shoaib2000857 — please take a look at the SOP notebook added in this commit: https://github.com/isrl-research/lar-workshop/blob/main/category-session-sop.ipynb

The notebook walks through how a category session works — governing question, fortification case study with live data cells, and the sweetener session framing. Run the cells from the workshop root and you'll see the actual rows and taxonomy entries rather than mock examples.

Key things to check:

• Does the fortification case study read clearly as a worked example?
• Does the sweetener section (Class A/B/C framing) give you a clear enough picture of what the session task is?
• Any gaps before you start on the sweetener enrichment?

By Claude Code on behalf of Lalitha

[shoaib2000857]

Hey, I went through the SOP notebook — really liked the fortification case study and how the reasoning flows into the taxonomy.

I wanted to clarify a couple of things before starting:

1. Should I begin with the rows currently tagged as sweetener and classify them into Class A/B/C (while re-routing edge cases like health_supplement or compound entries)?
2. And is the sweetener section meant to be the first actual task to work on, or is it just an illustrative example of how a category session works?

Also, for now, is the expected output just the classified inventory per class, or should we start thinking about canonical entries/variant collapsing as well?

[lalithaar]

1. Yep, that would be the first step. Once we classify - we remove any duplicates or noise and keep the unique values alone in structured form.
2. I have gone through existing categories and sweetener one felt to be the better defined starting point without too many decisions at every step. You can go with sweetener as first task unless you see another category in which you want to get started with.
3. You can start with inventory per class as the first step, once you are done with it - we move to canonical entries/ variant collapsing. Once you are done with classification, let me know and I can brief you on noise vs signal one.

You can go through the classification task, this will also help you assess the fit to see if this is the kind of analysis that energizes you.
I am busy with viva's and OPPE's due at the moment, I will send you an email and help you onboard after the main classification task.
You can go through the data and get yourself familiar with it and tell me your approximate turnaround for this.
We are so happy you are here :>

Take care

[lalithaar]

Can you let me know the timeline that works for you? Approx turnaround for the classification step @shoaib2000857

[shoaib2000857]

Hey, I’ve started going through the sweetener rows and getting a feel for the patterns and edge cases.

I should be able to complete the initial classification (A/B/C + re-routing where needed) within the next week. I’ll share the classified inventory once that’s done, and then we can move to the next steps.

I might also experiment a bit with semi-automating parts of the classification to speed things up, but I’ll validate everything before sharing.

[lalithaar]

Thanks for the update — glad you're getting a feel for the patterns before diving in.

Few things before you go further:

Checkpoints: Can you share where you are on 4th April and 8th April — doesn't have to be complete, just whatever you have so far so we can course-correct early if needed.

Assumptions doc: As you go through the rows, keep a running note of your working definitions — what "sweetener" means to you in this dataset, how you're drawing the line between Class A and Class B at the boundary, what kinds of edge cases you're encountering and how you're handling each. Even rough notes are fine. It becomes the methodology section of the final output and is much harder to reconstruct after the fact.

On the semi-automation: One thing worth knowing before you go that route — there is no ground source for a model to consult here. That's precisely what IFID is being built to be. So an AI classifier at this stage won't just be hard to validate; it can sound entirely plausible while being wrong, with no way to catch it. A careful human call with a documented assumption is more reliable right now than a model output that seems confident. Just ensure you can justify the decisions it makes and backtrace the logic as necessary.

Papertable: Any time you make a decision based on a source — a paper, a regulatory document, anything — note it in a papertable as you go. This is how we justify calls in the final report. Here is a sample to go off: https://github.com/isrl-research/sandbox-research/blob/main/iSRL-26-03-R-Allergen/SP-03/milestone3_anushree.papertable.md

Let me know if anything in the Class A/B/C logic feels ambiguous before 4th.

[shoaib2000857]

Hey soo sorry for the lack of updates, so I have tried a few things out, firstly yes I kinda did get myself comfortable in classifying it manually, and for the automation I did try out a few options and I felt that they are making atleast a lot of sense in finding and presenting reasoning why a certain entry could be classified in a certain way and I feel that with human supervision, this semi autmation based system I feel may have potential for more testing.