├── knowledge_graph.db # Merged KG across all videos (SQLite, primary)
36
├── knowledge_graph.json # Merged KG across all videos (JSON export)
37
└── videos/
38
├── meeting-01/
39
│ ├── manifest.json
40
│ ├── transcript/
41
│ ├── diagrams/
42
│ ├── captures/
43
│ └── results/
44
│ ├── analysis.md
45
│ ├── analysis.html
46
│ ├── knowledge_graph.db
47
│ ├── knowledge_graph.json
48
│ ├── key_points.json
49
│ └── action_items.json
50
└── meeting-02/
51
├── manifest.json
52
└── ...
53
```
54
55
## Knowledge graph merging
56
57
When the same entity appears across multiple videos, PlanOpticon merges them using a multi-strategy approach:
58
59
### Entity deduplication
60
61
- **Case-insensitive exact matching** -- `"kubernetes"` and `"Kubernetes"` are recognized as the same entity
62
- **Fuzzy name matching** -- Uses `SequenceMatcher` with a threshold of 0.85 to unify near-duplicate entities (e.g., `"K8s"` and `"k8s cluster"` may be matched depending on context)
63
- **Descriptions are unioned** -- All unique descriptions from each video are combined
64
- **Occurrences are concatenated with source tracking** -- Each occurrence retains its source video reference
65
66
### Relationship deduplication
67
68
- Relationships are deduplicated by (source, target, type) tuple
69
- Descriptions from duplicate relationships are merged
70
71
### Type conflict resolution
72
73
When the same entity appears with different types across videos, PlanOpticon uses a specificity ranking to resolve the conflict. More specific types are preferred over general ones:
74
75
- `technology` > `concept`
76
- `person` > `concept`
77
- `organization` > `concept`
78
- And so on through the full type hierarchy
79
80
This ensures that an entity initially classified as a generic `concept` in one video gets upgraded to `technology` if it is identified more specifically in another.
81
82
The merged knowledge graph is saved at the batch root in both SQLite (`knowledge_graph.db`) and JSON (`knowledge_graph.json`) formats, and is included in the batch summary as a Mermaid diagram.
83
84
## Error handling
85
86
If a video fails to process, the batch continues. Failed videos are recorded in the batch manifest with error details:
87
88
```json
89
{
90
"video_name": "corrupted-file",
91
"status": "failed",
92
"error": "Audio extraction failed: no audio track found"
After batch processing completes, the merged knowledge graph at the batch root contains entities and relationships from all successfully processed videos. You can query it just like a single-video knowledge graph:
planopticon wiki generate output/knowledge_graph.db -o ./wiki
153
```
154
155
### Classify for planning
156
157
Run taxonomy classification on the merged graph to categorize entities across all videos:
158
159
```bash
160
planopticon kg classify output/knowledge_graph.db
161
```
162
163
### Use with the planning agent
164
165
The planning agent can consume the merged knowledge graph for cross-video analysis and planning:
166
167
```bash
168
planopticon agent --db output/knowledge_graph.db
169
```
170
171
### Incremental batch processing
172
173
If you add new videos to the recordings directory, you can re-run the batch command. Videos that have already been processed (with output directories present) will be detected via checkpoint/resume within each video's pipeline, making incremental processing efficient.