Establish project architecture and design decisions

2026-07-11 16:27:59 +02:00
parent 3946b88d12
commit 5b4d52b201
11 changed files with 217 additions and 0 deletions
@@ -0,0 +1,104 @@
+# 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.