Designing Source-Grounded AI Answers for Meeting Search

AI meeting tools are getting better at generating summaries.

That is useful.

But summaries are only one part of the problem.

The harder question is:

Can users ask questions across past conversations and trust the answer?

For example:

What did the customer say about onboarding friction?

Which risks did we mention during the launch planning meetings?

Did we already decide on the pricing model?

Who owns the follow-up from the last product review?

These are not just search queries.

They are context questions.

At Cheetu AI, we think the next generation of AI meeting tools should not only return answers.

They should return answers with sources.

That means every answer should connect back to the original meeting, speaker, timestamp, and transcript segment.

This post breaks down how to think about designing source-grounded AI answers for meeting search.

Why Meeting Search Is Different From Document Search

Searching meeting content is not the same as searching documents.

Documents are usually edited, structured, and intentional.

Meetings are different.

They are messy.

People interrupt each other.
Topics shift quickly.
Decisions happen gradually.
Action items may be implied instead of clearly stated.
Important context may come from tone, timing, or who said something.

A document might say:

We decided to move forward with a tiered pricing model.

A meeting might contain the same decision across several moments:

Sarah: I think three tiers make sense for launch.

James: Annual discounts would help with cash flow.

Taylor: Let's keep add-ons out of scope for now.

Alex: Agreed. Let's move forward with the core plans first.

A search system needs to understand that these fragments may belong to one decision.

That is why meeting search needs more than keyword matching.

It needs:

• Transcript structure
• Speaker metadata
• Timestamps
• Topic grouping
• Semantic retrieval
• Summary context
• Source-grounded answer generation
• The Basic Data Model

A source-grounded meeting search system starts with structured transcript segments.

A simple segment object might look like this:

{
  "segment_id": "seg_1024",
  "meeting_id": "meeting_q2_strategy",
  "meeting_title": "Q2 Product Strategy Review",
  "speaker": "Sarah",
  "speaker_role": "Product",
  "start_time": "00:12:34",
  "end_time": "00:12:58",
  "text": "I recommend we move forward with a tiered pricing model: Starter, Pro, and Enterprise.",
  "language": "en"
}

This gives the system enough information to return a useful source later.

But for better retrieval, we usually need more metadata.

{
  "segment_id": "seg_1024",
  "meeting_id": "meeting_q2_strategy",
  "meeting_title": "Q2 Product Strategy Review",
  "meeting_type": "strategy",
  "speaker": "Sarah",
  "speaker_role": "Product",
  "start_time": "00:12:34",
  "end_time": "00:12:58",
  "text": "I recommend we move forward with a tiered pricing model: Starter, Pro, and Enterprise.",
  "topics": ["pricing", "packaging", "launch"],
  "entities": ["Starter", "Pro", "Enterprise"],
  "summary_section": "Decisions",
  "importance": "high"
}

This metadata helps the system answer questions like:

What pricing decisions did we make?

or:

Show me product strategy decisions from Q2 planning meetings.
From Transcript Segments to Retrieval Chunks

From Transcript Segments to Retrieval Chunks

Individual transcript segments are often too small.

A single sentence may not provide enough context.

But full meeting transcripts are too large.

The solution is chunking.

A chunk is a group of related transcript segments.

It may represent:

• A topic discussion
• A decision sequence
• A question and answer
• A customer objection
• A risk discussion
• An action item assignment

Example:

{
  "chunk_id": "chunk_pricing_decision_001",
  "meeting_id": "meeting_q2_strategy",
  "title": "Pricing model decision",
  "start_time": "00:12:34",
  "end_time": "00:16:10",
  "text": "Sarah recommended a tiered pricing model. James suggested annual discounts. Taylor proposed keeping add-ons out of scope. Alex agreed to move forward with core plans first.",
  "source_segments": ["seg_1024", "seg_1025", "seg_1026", "seg_1027"],
  "topics": ["pricing", "packaging", "annual discounts"],
  "summary_section": "Decisions"
}

A good chunk should preserve enough context for the model to answer correctly.

It should also preserve links back to the exact transcript segments.

The answer can be generated from the chunk, but trust comes from the source segments.

A Simple Retrieval Pipeline

A meeting search pipeline might look like this:

Audio
  ↓
Real-time transcription
  ↓
Speaker labels + timestamps
  ↓
Transcript segments
  ↓
Topic-aware chunks
  ↓
Embeddings + metadata index
  ↓
Semantic retrieval
  ↓
Answer generation
  ↓
Source-grounded response

Each layer has a job.

Layer Purpose
Transcription Convert speech into text
Speaker labels Preserve who said what
Timestamps Preserve when something was said
Chunks Group related context
Metadata Enable filtering and ranking
Search index Retrieve relevant context
Answer generation Produce a concise answer
Source grounding Let users verify the answer

The key design choice is not only how to generate the answer.

It is how to make the answer inspectable.

Designing the Search Request

A natural-language query should be easy for users.

For example:

What did we decide about the pricing model?

Behind the scenes, the system may convert that into a structured retrieval request.

{
  "query": "What did we decide about the pricing model?",
  "filters": {
    "topics": ["pricing"],
    "summary_section": ["Decisions"],
    "date_range": {
      "from": "2024-02-01",
      "to": "2024-04-30"
    }
  },
  "top_k": 5
}

This lets the system combine semantic search with metadata filters.

A query about “pricing model” may match:

• pricing
• packaging
• plan tiers
• annual discounts
• add-ons
• enterprise plan
• launch pricing That is why semantic retrieval matters.

But metadata keeps the results grounded.

Designing the Answer Object

A source-grounded AI answer should be structured.

Instead of returning only text, the API or internal object might return something like this:

{
  "answer": "We decided to move forward with a tiered pricing model with three plans: Starter, Pro, and Enterprise. Annual discounts of 20% were also discussed, and add-ons will be revisited in Q3.",
  "confidence": "medium-high",
  "sources": [
    {
      "meeting_title": "Q2 Product Strategy Review",
      "speaker": "Sarah",
      "speaker_role": "Product",
      "timestamp": "00:12:34",
      "excerpt": "I recommend we move forward with a tiered pricing model: Starter, Pro, and Enterprise."
    },
    {
      "meeting_title": "Q2 Product Strategy Review",
      "speaker": "James",
      "speaker_role": "Finance",
      "timestamp": "00:12:56",
      "excerpt": "Annual plans with a 20% discount make sense for cash flow and retention."
    },
    {
      "meeting_title": "Pricing Workshop",
      "speaker": "Taylor",
      "speaker_role": "Product",
      "timestamp": "00:08:15",
      "excerpt": "Let's keep add-ons out of scope for now and revisit in Q3."
    }
  ]
}

This format is useful because the answer can be rendered in multiple UI patterns:

• A short answer card
• A source list
• A timeline view
• A transcript highlight
• A meeting-level summary
• A citation-style response

The important principle is simple:

Never make the user trust the generated answer alone. Show where it came from.

UI Pattern: Answer First, Sources Second

For most users, the best UI is not a raw search result list.

It is:

1. Answer
2. Sources
3. Transcript excerpts
4. Link to full meeting context

For example:

Answer

We decided to move forward with a tiered pricing model with three plans:
Starter, Pro, and Enterprise. Annual discounts of 20% were discussed.
Add-ons will be revisited in Q3.

Sources

1. Q2 Product Strategy Review
   00:12:34
   Sarah, Product
   "I recommend we move forward with a tiered pricing model..."

2. Q2 Product Strategy Review
   00:12:56
   James, Finance
   "Annual plans with a 20% discount make sense..."

3. Pricing Workshop
   00:08:15
   Taylor, Product
   "Let's keep add-ons out of scope for now..."

This structure gives users a fast answer and a way to inspect it.

That matters because meeting content often drives decisions.

A user should be able to ask:

Where did this answer come from?
Who said it?
Was this a decision or just a suggestion?
Was there disagreement?
What happened before and after this quote?

The UI should make those questions easy to answer.

Ranking Sources

Not all sources should be treated equally.

A good meeting search system should rank sources based on more than semantic similarity.

Useful ranking signals include:

• Semantic relevance
• Recency
• Speaker role
• Meeting type
• Explicit decision markers
• Number of related mentions
• Summary importance
• User permissions
• Source quality
• Timestamp proximity to decision phrases

For example, if the user asks:

What did we decide about pricing?

A source from a meeting section labeled Decisions should probably rank higher than a random mention of “pricing” in a brainstorm.

A ranking object might include scores:

{
  "source_id": "seg_1024",
  "semantic_score": 0.91,
  "metadata_score": 0.82,
  "recency_score": 0.64,
  "decision_score": 0.95,
  "final_score": 0.88
}

This helps avoid returning sources that sound related but do not actually answer the question.

Handling Uncertainty

Not every question has a clean answer.

Sometimes the meeting did not contain a final decision.

Sometimes there were conflicting opinions.

Sometimes the transcript quality was low.

Sometimes the system found related discussion but no conclusion.

The UI should not pretend certainty.

Instead of saying:

We decided to launch in June.

It might say:

I found discussion about a June launch, but no final decision. The team mentioned June as a target date in two meetings, and one open question remained about resourcing.

This is a better answer.

It is more honest.

It also helps users decide what to do next.

Useful uncertainty states include:

• No answer found
• Related discussion found
• Conflicting sources found
• Draft decision found
• Final decision found
• Low transcript confidence
• Missing speaker attribution

A simple response might look like this:

{
  "answer": "I found related discussion about a June launch, but no final decision.",
  "status": "related_discussion_found",
  "sources": [
    {
      "meeting_title": "Launch Planning",
      "timestamp": "00:18:22",
      "speaker": "Jordan",
      "excerpt": "June is possible if design signs off by the end of May."
    }
  ],
  "open_questions": [
    "Is the design sign-off date confirmed?",
    "Has resourcing been approved?"
  ]
}

This kind of answer is more useful than a confident guess.

Permissions Matter

Meeting memory can contain sensitive information.

A search system should respect access control.

Users should only retrieve content they are allowed to see.

Permission checks may need to happen at multiple levels:

• Workspace
• Team
• Meeting
• Participant
• Transcript segment
• Summary
• Shared folder or project
• Customer account

A simple permission-aware retrieval function might look like this:

def search_conversation_memory(user, query, filters):
    allowed_meetings = get_allowed_meetings(user)

    results = retrieve_chunks(
        query=query,
        filters={
            **filters,
            "meeting_ids": allowed_meetings
        }
    )

    return generate_source_grounded_answer(
        query=query,
        chunks=results
    )

This is not just a security detail.

It is part of user trust.

If conversation memory feels uncontrolled, users will not want to use it.

What Makes a Good Source-Grounded Answer?

A good answer should be:

• Clear
• Concise
• Traceable
• Honest about uncertainty
• Connected to transcript evidence
• Easy to inspect
• Permission-aware
• Useful for action

A weak answer says:

The team discussed pricing.

A better answer says:

The team decided to move forward with three pricing tiers: Starter, Pro, and Enterprise. James suggested a 20% annual discount, and Taylor recommended keeping add-ons out of scope until Q3.

A great answer adds:

Sources:
- Q2 Product Strategy Review, 00:12:34, Sarah
- Q2 Product Strategy Review, 00:12:56, James
- Pricing Workshop, 00:08:15, Taylor

That final layer is what turns AI output into usable knowledge.

How This Fits Into Cheetu AI

Cheetu AI is built around the idea that conversations should become searchable memory.

The product combines:

• Real-time transcription
• Live translation
• AI summaries
• AI chat across past calls, meetings, lectures, and notes

But the core principle is not simply “generate AI output.”

The core principle is:

Help users understand where the answer came from.

That is why source context matters.

A conversation memory system should help users stay present during the meeting and still find what matters after it ends.

Final Thought

AI meeting search should not feel like asking a black box.

It should feel like asking your own conversation archive.

The answer should be clear.

The sources should be visible.

The original context should be one click away.

That is how AI meeting tools can move beyond notes and summaries.

They can become memory systems people actually trust.

Learn more: Cheetu AI