275 lines
3.2 KiB
Markdown
275 lines
3.2 KiB
Markdown
# 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:
|
|
|
|
```json
|
|
{
|
|
"priority": "...",
|
|
"confidence": 0.93,
|
|
"risk": "...",
|
|
"category": "...",
|
|
"importance": "...",
|
|
"status": "..."
|
|
}
|
|
```
|
|
|
|
Good:
|
|
|
|
```json
|
|
{
|
|
"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
|
|
|
|
```json
|
|
{
|
|
"meeting_id": "meeting_001",
|
|
"language": "en",
|
|
"blocks": []
|
|
}
|
|
```
|
|
|
|
---
|
|
|
|
# Discussion Block
|
|
|
|
The discussion block is the fundamental processing unit.
|
|
|
|
```json
|
|
{
|
|
"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.
|
|
|
|
```json
|
|
{
|
|
"chunk_id": 3,
|
|
"blocks": [
|
|
40,
|
|
41,
|
|
42
|
|
]
|
|
}
|
|
```
|
|
|
|
Chunks are implementation details.
|
|
|
|
They never represent discussion topics.
|
|
|
|
---
|
|
|
|
# Topic
|
|
|
|
Represents one discussion topic.
|
|
|
|
```json
|
|
{
|
|
"topic_id": "topic_003",
|
|
"title": "Ventilation",
|
|
"segments": []
|
|
}
|
|
```
|
|
|
|
---
|
|
|
|
# Topic Segment
|
|
|
|
A continuous part of a topic.
|
|
|
|
```json
|
|
{
|
|
"start_block": 40,
|
|
"end_block": 152
|
|
}
|
|
```
|
|
|
|
One topic may contain multiple segments.
|
|
|
|
---
|
|
|
|
# Fact
|
|
|
|
```json
|
|
{
|
|
"text": "..."
|
|
}
|
|
```
|
|
|
|
---
|
|
|
|
# Question
|
|
|
|
```json
|
|
{
|
|
"text": "..."
|
|
}
|
|
```
|
|
|
|
---
|
|
|
|
# Position
|
|
|
|
```json
|
|
{
|
|
"text": "...",
|
|
"speaker": "..."
|
|
}
|
|
```
|
|
|
|
---
|
|
|
|
# Decision
|
|
|
|
```json
|
|
{
|
|
"text": "..."
|
|
}
|
|
```
|
|
|
|
---
|
|
|
|
# Todo
|
|
|
|
```json
|
|
{
|
|
"text": "...",
|
|
"owner": "..."
|
|
}
|
|
```
|
|
|
|
Owner remains empty if unknown.
|
|
|
|
---
|
|
|
|
# Technical Detail
|
|
|
|
```json
|
|
{
|
|
"text": "..."
|
|
}
|
|
```
|
|
|
|
---
|
|
|
|
# Topic Result
|
|
|
|
After extraction, every topic contains the collected information.
|
|
|
|
```json
|
|
{
|
|
"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.
|
|
|
|
```json
|
|
{
|
|
"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. |