104 lines
2.3 KiB
Markdown
104 lines
2.3 KiB
Markdown
# ADR 0008: Meeting Storage Layout
|
|
|
|
## Status
|
|
|
|
Accepted
|
|
|
|
## Context
|
|
|
|
A meeting produces multiple related artifacts during its lifecycle, including recordings, transcripts, AI-generated analyses, exports and metadata.
|
|
|
|
The project requires a storage layout that is:
|
|
|
|
- human-readable
|
|
- portable
|
|
- independent of the storage backend
|
|
- suitable for long-term archival
|
|
- compatible with future database indexing
|
|
|
|
---
|
|
|
|
## Decision
|
|
|
|
Each meeting shall be stored in its own directory.
|
|
|
|
The directory represents the canonical container for all meeting artifacts.
|
|
|
|
Meeting directories shall be named using a stable Meeting ID rather than the meeting title.
|
|
|
|
Recommended format:
|
|
|
|
```text
|
|
YYYYMMDD_HHMMSS_<short_uuid>
|
|
```
|
|
|
|
Example:
|
|
|
|
```text
|
|
20260711_154215_9d7a4c51
|
|
```
|
|
|
|
The meeting title is stored exclusively inside `meeting.json`.
|
|
|
|
A meeting shall follow the structure:
|
|
|
|
```text
|
|
meeting/
|
|
│
|
|
├── meeting.json
|
|
│
|
|
├── recording/
|
|
│ ├── source.wav
|
|
│ └── archive.flac
|
|
│
|
|
├── transcript/
|
|
│ ├── canonical.json
|
|
│ ├── working_v1.json
|
|
│ └── working_v2.json
|
|
│
|
|
├── artifacts/
|
|
│ ├── summary.md
|
|
│ ├── executive_summary.md
|
|
│ ├── action_items.json
|
|
│ ├── decisions.json
|
|
│ ├── risks.json
|
|
│ └── knowledge.json
|
|
│
|
|
├── export/
|
|
│ ├── protocol.md
|
|
│ ├── protocol.pdf
|
|
│ └── protocol.docx
|
|
│
|
|
└── metadata/
|
|
├── recording.json
|
|
├── transcription.json
|
|
├── diarization.json
|
|
└── llm.json
|
|
```
|
|
|
|
The file system is considered the primary storage format.
|
|
|
|
Databases are optional secondary indexes.
|
|
|
|
File names describe their role rather than their file format.
|
|
|
|
Examples:
|
|
|
|
- `source.wav`
|
|
- `archive.flac`
|
|
- `canonical.json`
|
|
- `working_v1.json`
|
|
|
|
This allows processing and archive formats to evolve without changing the overall storage layout.
|
|
|
|
---
|
|
|
|
## Consequences
|
|
|
|
- Every meeting is self-contained.
|
|
- Meetings can be copied, archived and restored independently.
|
|
- Backup procedures remain simple.
|
|
- Future storage implementations remain compatible.
|
|
- Database implementations can be rebuilt from the meeting directories.
|
|
- Meeting titles may change without affecting directory names or references.
|
|
- The storage layout remains stable even if processing or archive formats evolve in the future. |