Revisit the vault-note process for retrieval and context cost #1574

New issue

Closed

opened 2026-11-05 15:56:57 +00:00 by jared · 2 comments

jared commented

2026-11-05 15:56:57 +00:00

Owner

Problem

Jared asked whether the vault-note process should change. The vault is long-term memory for the AI, so a note should answer a future question at low context cost. No one has tested whether smaller, focused notes do this better. This ticket records the idea only. It has no design.

Jared's words, verbatim:

Another thing this has me wondering is - should we revisit the vault-note process? Also, something to consider AFTER graphify is at its most useful with what currently exists. I will tangent for a second though. The main point of of these vault notes is to provide a longer-term memory for the AI. That means the notes it creates should be optimized to answer future questions. Big notes usually answer many questions with added context as a cost. Smaller notes could answer one focused and useful question and provide evidence for the answer, and the context cost is much smaller. I guess I am thinking that it might be better to look at our existing vault notes, and consider how would could better organize, explain (like /orwell-writing or /os-sdlc:technical-communication), and illustrate (tables, stats, etc) evidence to support the knowledge nuggets so it is both easy to find through graphify and embeddings and useful when found, without bloating context or slowing the flow.

Observed

Focused notes also give only one node in 30 to 44% of cases.

The note-split half of #1570 moves to this ticket. #1570 keeps the query cap.

This ticket waits for graphify sign-off on #1540. Do not start it before then. Capture applies no state labels, so the wait is stated here and no waiting label is set.

Reproduce

n/a: this is a process question, and nothing is broken.

Origin

Trigger: Jared's remark during the graph retrieval work, session b10276a0.
Improvised this session: none.
Chain: vault retrieval cost and quality depend on note size ← notes are written large and give hub nodes or single nodes ← DESIGN (#1570, #1540).
Root candidate: none found; searched vault, graphify, embedding, note split, note size, hub notes, summary
Where: plugins/os-vault
Session: b10276a0-3582-48b5-b0fe-f13795bdcc75
Transcript: /home/jared/.claude/projects/-home-jared-Documents-SecondBrain/b10276a0-3582-48b5-b0fe-f13795bdcc75.jsonl
Parent: #1540.

VERDICT: CREATE

## Problem Jared asked whether the vault-note process should change. The vault is long-term memory for the AI, so a note should answer a future question at low context cost. No one has tested whether smaller, focused notes do this better. This ticket records the idea only. It has no design. Jared's words, verbatim: > Another thing this has me wondering is - should we revisit the vault-note process? Also, something to consider AFTER graphify is at its most useful with what currently exists. I will tangent for a second though. The main point of of these vault notes is to provide a longer-term memory for the AI. That means the notes it creates should be optimized to answer future questions. Big notes usually answer many questions with added context as a cost. Smaller notes could answer one focused and useful question and provide evidence for the answer, and the context cost is much smaller. I guess I am thinking that it might be better to look at our existing vault notes, and consider how would could better organize, explain (like /orwell-writing or /os-sdlc:technical-communication), and illustrate (tables, stats, etc) evidence to support the knowledge nuggets so it is both easy to find through graphify and embeddings and useful when found, without bloating context or slowing the flow. ## Observed Focused notes also give only one node in 30 to 44% of cases. The note-split half of #1570 moves to this ticket. #1570 keeps the query cap. This ticket waits for graphify sign-off on #1540. Do not start it before then. Capture applies no state labels, so the wait is stated here and no `waiting` label is set. ## Reproduce n/a: this is a process question, and nothing is broken. ## Origin - Trigger: Jared's remark during the graph retrieval work, session b10276a0. - Improvised this session: none. - Chain: vault retrieval cost and quality depend on note size ← notes are written large and give hub nodes or single nodes ← DESIGN (#1570, #1540). - Root candidate: none found; searched vault, graphify, embedding, note split, note size, hub notes, summary - Where: plugins/os-vault - Session: b10276a0-3582-48b5-b0fe-f13795bdcc75 - Transcript: /home/jared/.claude/projects/-home-jared-Documents-SecondBrain/b10276a0-3582-48b5-b0fe-f13795bdcc75.jsonl - Parent: #1540. VERDICT: CREATE

jared added the

plugin/os-vault

filed-by/user

category/investigation

labels

2026-11-05 15:56:57 +00:00

jared referenced this issue

2026-11-05 15:59:25 +00:00

Cap or split hub notes so one note cannot crowd out query results #1570

jared referenced this issue

2026-11-06 21:30:53 +00:00

Cap or split hub notes so one note cannot crowd out query results #1570

jared commented

2026-11-06 22:15:57 +00:00

Author

Owner

Resolution

Done: The write skill now requires a summary that states the answer in the words of a future question, under 400 characters, and to split a note that needs more. No split or rewrite of existing notes.

Evidence: main e65b7b68. Card search reads title, file name, and summary, and reached 12/13 reworded. No question failed from note size. 25 of 334 notes have no summary; a bulk rewrite re-extracts each edited note on the GPU and no failing question justifies it. Ruling 74.

Follow-ups: none

## Resolution **Done:** The write skill now requires a summary that states the answer in the words of a future question, under 400 characters, and to split a note that needs more. No split or rewrite of existing notes. **Evidence:** main e65b7b68. Card search reads title, file name, and summary, and reached 12/13 reworded. No question failed from note size. 25 of 334 notes have no summary; a bulk rewrite re-extracts each edited note on the GPU and no failing question justifies it. Ruling 74. **Follow-ups:** none

jared closed this issue

2026-11-06 22:15:58 +00:00

jared referenced this issue from a commit

2026-11-06 22:17:59 +00:00

docs(os-vault): record the #1573 scores and set the summary rule (#1574)

jared commented

2026-11-06 22:17:59 +00:00

Author

Owner

Correction to the close evidence: the summary rule landed in 80bd44df, not e65b7b68.

Correction to the close evidence: the summary rule landed in 80bd44df, not e65b7b68.