Context Health Explained: When to Reupload, Reindex, or Ignore
A practical guide to freshness signals in Snipara: what reindex actually does, when a reupload is required, how stale sources affect LLM answers, and how health applies to business files, code docs, and parsed diagrams.
Alex Lopez
Founder, Snipara
- Readable in 8 minutes
- Published 2026-04-27
- 7 context themes covered
Context health exists because retrieval quality is not only a search problem. It is also a freshness problem. A file can be indexed perfectly and still be the wrong source to trust if the underlying snapshot is stale, the source changed, or the parser output should be reviewed.
Key Takeaways
- Reindex is for updating searchable chunks from the content already in Snipara.
- Reupload is for when the source of truth itself changed.
- Health signals help the user and the LLM distrust stale or degraded context before it causes a bad output.
- Business files and diagrams need health as much as code because stale offers and stale diagrams are operationally dangerous.
The Three Common Cases
| Signal | What it means | What to do |
|---|---|---|
| Index missing or outdated | Snipara content exists, but retrieval data should be refreshed | Reindex |
| Source changed after upload | The original file or external source no longer matches the uploaded snapshot | Reupload, then reindex if needed |
| Parser quality or stale snapshot concern | The extracted content may be degraded or too old to trust confidently | Review, then reupload or replace if necessary |
Reindex vs Reupload
This distinction is where many teams lose time. Reindex does not fetch a new source file. Reupload does not merely refresh search metadata. They solve different problems.
Reindex
Use it when the content already stored in Snipara should be re-chunked, re-parsed, or made immediately searchable again after processing changes.
Reupload
Use it when the real source file changed: new proposal draft, updated RFP, changed diagram, new PowerPoint, edited doc, or refreshed code snapshot.
What the LLM Should Do
A healthy runtime should not silently trust every file equally. When context is stale or uncertain, the model should change behavior.
- flag the stale or changed source explicitly;
- treat uncertain context as background, not authority;
- ask for a fresh upload if a critical answer depends on it;
- avoid presenting degraded sources as confirmed facts.
Bad behavior: answer confidently from a diagram uploaded six months ago after the source Visio was updated twice. Good behavior: identify the freshness issue and ask for a new snapshot if the current answer depends on it.
Where This Matters Most
- Business workflows — stale RFP attachments, old pricing language, or outdated client diagrams
- Code workflows — stale repo docs, outdated architecture notes, or schema changes not reflected in indexed context
- Binary parsers — SVG, VSDX, PPTX, DOCX, and PDF extractions that should sometimes be reviewed before being treated as strong evidence