meeting-lab/docs/data-models.md

Data Models

Purpose

This document describes the logical data structures exchanged between the pipeline stages of the Meeting Lab.

The goal is not to define a final database schema.

Instead, these models represent stable interfaces between processing modules.

Models should evolve only when required by new functionality.

---

Design Principles

Keep Models Small

Only include fields that are currently required.

Avoid speculative attributes.

Bad:

{
  "priority": "...",
  "confidence": 0.93,
  "risk": "...",
  "category": "...",
  "importance": "...",
  "status": "..."
}

Good:

{
  "text": "...",
  "owner": "..."
}

New fields can always be added later.

---

Preserve Information

Models should preserve information rather than interpret it.

Interpretation belongs to processing modules.

---

Stable Interfaces

Modules communicate only through documented data models.

A module must never depend on another module's internal implementation.

---

Transcript

Represents the complete meeting transcript.

Example

{
    "meeting_id": "meeting_001",
    "language": "en",
    "blocks": []
}

---

Discussion Block

The discussion block is the fundamental processing unit.

{
    "block_id": 42,
    "speaker": "Speaker A",
    "start": 351.2,
    "end": 367.8,
    "text": "..."
}

Required fields

• block_id
• text

Optional fields

• speaker
• timestamps

---

Chunk

Technical processing unit.

{
    "chunk_id": 3,
    "blocks": [
        40,
        41,
        42
    ]
}

Chunks are implementation details.

They never represent discussion topics.

---

Topic

Represents one discussion topic.

{
    "topic_id": "topic_003",
    "title": "Ventilation",
    "segments": []
}

---

Topic Segment

A continuous part of a topic.

{
    "start_block": 40,
    "end_block": 152
}

One topic may contain multiple segments.

---

Fact

{
    "text": "..."
}

---

Question

{
    "text": "..."
}

---

Position

{
    "text": "...",
    "speaker": "..."
}

---

Decision

{
    "text": "..."
}

---

Todo

{
    "text": "...",
    "owner": "..."
}

Owner remains empty if unknown.

---

Technical Detail

{
    "text": "..."
}

---

Topic Result

After extraction, every topic contains the collected information.

{
    "topic_id": "topic_003",
    "title": "Ventilation",

    "segments": [],

    "facts": [],
    "questions": [],
    "positions": [],
    "decisions": [],
    "todos": [],
    "technical_details": []
}

This object represents the main output of the analysis pipeline.

---

Meeting Result

The complete structured meeting.

{
    "meeting_id": "meeting_001",

    "topics": []
}

Protocol generation operates exclusively on this structure.

---

Future Extensions

Possible future additions include:

• confidence values
• evidence references
• source blocks
• priorities
• deadlines
• status tracking
• semantic relationships

These fields will only be introduced when they provide measurable benefits.

The Meeting Lab intentionally avoids designing an overly complex schema in advance.