This is the reason we rebuilt how Jarvis reads KB. Short answer: Jarvis reads the full file when it calls read_file on curated KB content. No truncation.
Longer answer for the why: we learned this the hard way on an early pilot. An 8k-char truncation on a procedure file caused Jarvis to miss the critical last step and generate a wrong fix. Since then:
- Full reads on anything under
kb/ (your curated content) - Truncation still applies to noisy inputs (raw email threads, very long customer chat transcripts) where the first N chars usually contain the signal
- Context budget is ~35k tokens per round, well inside the 200k window, so full reads fit comfortably even with 3-4 large files pulled in
The one knob you have: if a single file is over 100k chars, we do chunk it at header boundaries (preserving cross-refs within a header section). If your runbook has good h2 structure you won't notice. If it's one giant wall of text, add h2s.