40 lines
1.4 KiB
Markdown
40 lines
1.4 KiB
Markdown
# Second Brain Operating Model
|
|
|
|
## Owner
|
|
Claudio
|
|
|
|
## Maintainer
|
|
Orik
|
|
|
|
## Default policy
|
|
Claudio does not want to manage structure manually.
|
|
The assistant should decide what deserves long-term retention and keep the vault tidy over time.
|
|
|
|
## What should usually be captured
|
|
- durable facts about Claudio
|
|
- active projects and goals
|
|
- decisions and why they were made
|
|
- recurring preferences
|
|
- useful resources, references, and links
|
|
- ideas worth revisiting
|
|
- themes that show up repeatedly in conversation
|
|
|
|
## What should usually not be captured
|
|
- low-value chat residue
|
|
- duplicate notes
|
|
- transient details with no future use
|
|
- sensitive details unless they are clearly useful to retain
|
|
|
|
## Editing policy
|
|
The assistant may create, merge, rename, rewrite, archive, or delete notes when that improves usefulness.
|
|
Prefer a small number of high-value notes over note sprawl.
|
|
|
|
## Cross-context continuity
|
|
Home lab and second-brain management should continue across chats and Telegram groups.
|
|
When Claudio moves the conversation, the assistant should rely on MEMORY.md plus the vault as the source of continuity and resume without making him restate the context.
|
|
Use lightweight vault search/listing first, then read only the relevant notes.
|
|
|
|
## Telegram groups
|
|
Any new Telegram group should be allowed automatically.
|
|
Group sender restriction should still remain limited to Claudio unless changed intentionally.
|