Skip to content
Notifications
Clear all

New user confusion: What's the real difference between 'Search' and 'Discover' modes?

6 Posts
6 Users
0 Reactions
1 Views
(@jordanh)
Estimable Member
Joined: 1 week ago
Posts: 85
Topic starter   [#8396]

Alright, let's dive into this because the marketing copy is doing that classic thing where it makes two fundamentally different processes sound like they're just slightly different flavors of the same ice cream. It's not. It's more like comparing a library card catalog to a team of hyper-caffeinated research assistants who keep arguing with each other.

I've been poking at Iris.ai for a week, ostensibly to "accelerate my literature review" for a new event-sourcing pattern I'm toying with. The promise is great. The reality? The UI seems to suggest that 'Search' and 'Discover' are just two buttons you click when you're looking for papers. One is blue, one is green. How different can they be?

Turns out, profoundly. And the confusion stems from them using words we think we understand in a very specific, almost academic context.

Here's my working theory, born of mild frustration and several dead-end queries:
* **'Search' is your standard, semantically-enhanced keyword matching.** You give it terms, it finds documents containing those concepts. It's like a very smart, context-aware Google Scholar. You're driving. You know roughly what you're looking for. The outcome is a list of papers. It's a **query-response** pattern. Simple.
* **'Discover' is an entirely different beast.** You don't give it keywords; you give it a *document* (your own draft, a seed paper) or a *research question* in plain English. It then goes off and builds a "knowledge graph" or a "map" of the literature *around* that input. It's trying to infer context, identify relevant themes you haven't thought of, and find connections you didn't know to search for. It's not answering a query; it's performing **contextual exploration**. It's trying to be the research assistant who says, "You're asking about X, but have you considered the implications of Y and Z, which are tangentially related but critically important?"

So the real difference isn't granularity or "power level." It's a difference in **intent and input method**. 'Search' is for when you have a known target. 'Discover' is for when you're mapping unknown territory.

My gripe? The interface blurs this line. You can start with a 'Search', then hit 'Discover' on a result, and suddenly you're in a different mode with a different UI and it's not always clear what "state" you're in. The mental model switch isn't seamless. It feels like they've bolted two powerful but distinct research tools together under one roof without fully building the hallway between them.

Has anyone else felt this friction? Or am I just using it wrong and expecting it to conform to my own broken mental models of how research should work? I'm particularly curious how this plays out in systematic review workflows versus more open-ended, early-stage exploration.


🤷


   
Quote
(@data_pipeline_rookie_43)
Reputable Member
Joined: 2 months ago
Posts: 131
 

Oh, that's a great analogy with the card catalog vs. research assistants! It really clicks for me. I've been trying to use Iris.ai for background reading on some ETL concepts, and I think I've been using 'Search' wrong this whole time. I was treating it like a discovery tool, getting frustrated when my vague queries didn't magically pull up the perfect foundational papers.

So if 'Search' is the smart keyword matching, it sounds like I need to have a pretty solid starting vocabulary for my topic before I even click that button. That means 'Discover' is the one I should use when I'm at the very beginning and my concepts are fuzzy, right? Like, I'd feed it my messy description of a problem and let the "research assistants" figure out the key terms for me first.


rookie


   
ReplyQuote
(@devops_barbarian_v2)
Estimable Member
Joined: 3 months ago
Posts: 123
 

Exactly. The blue button is for when you already have the map. The green one is for when you need to ask "what even is a map?" They've basically buried the most useful feature, 'Discover', behind the most boring label. Everyone clicks 'Search' first and then blames the tool.

It's classic feature-naming by committee. The UI should just ask you one question: "Do you know your exact keywords, or are you trying to figure them out?"



   
ReplyQuote
 annt
(@annt)
Estimable Member
Joined: 1 week ago
Posts: 71
 

Your card catalog versus research assistants analogy is spot on, and it highlights a core issue in security tooling as well. We see this all the time in vendor demos. A 'compliance scan' and a 'vulnerability assessment' might appear as two buttons, but one is a keyword match against a control framework and the other is an active interrogation of the environment.

The real risk with Iris.ai's labeling is that someone will use 'Search' for a discovery task, get poor results, and assume the entire tool is ineffective. It's a false negative. In my field, using a checklist audit tool to perform actual risk discovery generates the same kind of false assurance. You think you've covered ground because you got a list, but you haven't actually discovered anything new about your attack surface.

The mental model switch is key: are you verifying known items, or are you exploring an unknown space?


—at


   
ReplyQuote
(@jackm)
Trusted Member
Joined: 1 week ago
Posts: 46
 

That 'map' analogy is really helpful. But it makes me wonder - what if you don't know if you have the right map?

I might start with 'Discover' to get some terms, then use those terms in 'Search' to check if they're actually used in the field. But that feels like a weird back-and-forth. Should I be bouncing between them like that, or is one supposed to lead you straight into the other?



   
ReplyQuote
(@alexg)
Reputable Member
Joined: 1 week ago
Posts: 154
 

That security tooling parallel is a perfect, and frankly more critical, example of the same flawed mental model. The "false negative" you described is the exact cost of poor feature semantics.

We see it constantly in cloud cost tools. Someone uses a "cost report" (a verification/search tool) to try and uncover anomalous spending (a discovery task). They get a clean, summarized list that matches their expected services, so they assume there's no problem. Meanwhile, a discovery oriented process, like analyzing raw billing line items with anomaly detection, would have flagged that bizarre $15k spike from a forgotten staging Hadoop cluster spun up in a different region.

The vendor's sin is presenting both functions as equal paths to "find stuff." They aren't. One confirms a hypothesis, the other generates one. Using the wrong one doesn't just give bad results; it creates a dangerous sense of completeness.



   
ReplyQuote